* [PATCH v2 0/7] Add anx6345 DP/eDP bridge for Olimex Teres-I
@ 2019-06-04 12:21 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:21 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
ANX6345 LVTTL->eDP video bridge, driver with device tree bindings.
Changes from v1:
* fixed up copyright information. Most code changes are only moves and thus
retain copyright and module ownership. Even the new analogix-anx6345.c originates
from the old 1495-line analogix-anx78xx.c, with 306 insertions and 987 deletions
(ignoring the trivial anx78xx -> anx6345 replacements) 306 new vs. 508 old...
* fixed all minor formatting issues brought up
* merged previously separate new analogix_dp_i2c module into existing analogix_dp
* split additional defines into a preparatory patch
* renamed the factored-out common functions anx_aux_* -> anx_dp_aux_*, because
anx_...aux_transfer was exported globally. Besides, it is now GPL-only exported.
* moved chip ID read into a separate function.
* keep the chip powered after a successful probe.
(There's a good chance that this is the only display during boot!)
* updated the binding document: LVTTL input is now required, only the output side
description is optional.
Laurent: I have also looked into the drm_panel_bridge infrastructure,
but it's not that trivial to convert these drivers to it.
Changes from the respective previous versions:
* the reset polarity is corrected in DT and the driver;
things should be clearer now.
* as requested, add a panel (the known innolux,n116bge) and connect
the ports.
* renamed dvdd?? to *-supply to match the established scheme
* trivial update to the #include list, to make it compile in 5.2
Torsten
^ permalink raw reply [flat|nested] 90+ messages in thread
* [PATCH v2 0/7] Add anx6345 DP/eDP bridge for Olimex Teres-I
@ 2019-06-04 12:21 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:21 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
ANX6345 LVTTL->eDP video bridge, driver with device tree bindings.
Changes from v1:
* fixed up copyright information. Most code changes are only moves and thus
retain copyright and module ownership. Even the new analogix-anx6345.c originates
from the old 1495-line analogix-anx78xx.c, with 306 insertions and 987 deletions
(ignoring the trivial anx78xx -> anx6345 replacements) 306 new vs. 508 old...
* fixed all minor formatting issues brought up
* merged previously separate new analogix_dp_i2c module into existing analogix_dp
* split additional defines into a preparatory patch
* renamed the factored-out common functions anx_aux_* -> anx_dp_aux_*, because
anx_...aux_transfer was exported globally. Besides, it is now GPL-only exported.
* moved chip ID read into a separate function.
* keep the chip powered after a successful probe.
(There's a good chance that this is the only display during boot!)
* updated the binding document: LVTTL input is now required, only the output side
description is optional.
Laurent: I have also looked into the drm_panel_bridge infrastructure,
but it's not that trivial to convert these drivers to it.
Changes from the respective previous versions:
* the reset polarity is corrected in DT and the driver;
things should be clearer now.
* as requested, add a panel (the known innolux,n116bge) and connect
the ports.
* renamed dvdd?? to *-supply to match the established scheme
* trivial update to the #include list, to make it compile in 5.2
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] 90+ messages in thread
* [PATCH v2 1/7] drm/bridge: move ANA78xx driver to analogix subdirectory
2019-06-04 12:21 ` Torsten Duwe
@ 2019-06-04 12:22 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
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>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
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 +
drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
drivers/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 ee777469293a..862789bf64a0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -16,16 +16,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 e930ff9b5cd4..704fb0f41dc3 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,4 +1,14 @@
# SPDX-License-Identifier: GPL-2.0-only
+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 fdbf3fd2f087..6fcbfd3ee560 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
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.16.4
^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 1/7] drm/bridge: move ANA78xx driver to analogix subdirectory
@ 2019-06-04 12:22 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
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>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
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 +
drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
drivers/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 ee777469293a..862789bf64a0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -16,16 +16,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 e930ff9b5cd4..704fb0f41dc3 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,4 +1,14 @@
# SPDX-License-Identifier: GPL-2.0-only
+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 fdbf3fd2f087..6fcbfd3ee560 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
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.16.4
_______________________________________________
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] 90+ messages in thread
* [PATCH v2 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers
2019-06-04 12:21 ` Torsten Duwe
@ 2019-06-04 12:22 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
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>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 465 +--------------------
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 256 ++++++++++++
.../drm/bridge/analogix/analogix-i2c-txcommon.h | 242 +++++++++++
3 files changed, 503 insertions(+), 460 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..3fbe2c3244fd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
@@ -11,13 +11,15 @@
* GNU General Public License for more details.
*
*/
-
#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 +227,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..5a54c6d86428
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -0,0 +1,256 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on anx7808 driver obtained from chromeos with copyright:
+ * Copyright(c) 2013, Google Inc.
+ *
+ */
+#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..f48293f86f9d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -0,0 +1,242 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#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.16.4
^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers
@ 2019-06-04 12:22 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
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>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 465 +--------------------
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 256 ++++++++++++
.../drm/bridge/analogix/analogix-i2c-txcommon.h | 242 +++++++++++
3 files changed, 503 insertions(+), 460 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..3fbe2c3244fd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
@@ -11,13 +11,15 @@
* GNU General Public License for more details.
*
*/
-
#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 +227,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..5a54c6d86428
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -0,0 +1,256 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on anx7808 driver obtained from chromeos with copyright:
+ * Copyright(c) 2013, Google Inc.
+ *
+ */
+#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..f48293f86f9d
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -0,0 +1,242 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#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.16.4
_______________________________________________
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] 90+ messages in thread
* [PATCH v2 3/7] drm/bridge: extract some Analogix I2C DP common code
2019-06-04 12:21 ` Torsten Duwe
@ 2019-06-04 12:22 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
From: Icenowy Zheng <icenowy@aosc.io>
Some code can be shared within different DP bridges by Analogix.
Extract them to analogix_dp.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/Makefile | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +----------------
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 173 +++++++++++++++++++++
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 3 +
4 files changed, 178 insertions(+), 146 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index 6fcbfd3ee560..7623b9b80167 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
-analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.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/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index c09aaf93ae1b..f36ae51c641d 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_dp_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..d6016f789d80
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on anx7808 driver obtained from chromeos with copyright:
+ * Copyright(c) 2013, Google Inc.
+ *
+ */
+#include <linux/regmap.h>
+
+#include <drm/drm.h>
+#include <drm/drm_dp_helper.h>
+#include <drm/drm_print.h>
+
+#include "analogix-i2c-dptx.h"
+
+#define AUX_WAIT_TIMEOUT_MS 15
+#define AUX_CH_BUFFER_SIZE 16
+
+static int anx_i2c_dp_clear_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, 0);
+}
+
+static bool anx_dp_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_dp_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_dp_aux_op_finished(map_dptx)) {
+ if (time_after(jiffies, timeout)) {
+ if (!anx_dp_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_dp_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_dp_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_dp_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_dp_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_i2c_dp_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG,
+ SP_ADDR_ONLY);
+ if (err)
+ return err;
+
+ return msg->size;
+}
+EXPORT_SYMBOL_GPL(anx_dp_aux_transfer);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
index 5a54c6d86428..30436c88f181 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -253,4 +253,7 @@
/* DP AUX Buffer Data Registers */
#define SP_DP_BUF_DATA0_REG 0xf0
+ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
+ struct drm_dp_aux_msg *msg);
+
#endif
--
2.16.4
^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 3/7] drm/bridge: extract some Analogix I2C DP common code
@ 2019-06-04 12:22 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
From: Icenowy Zheng <icenowy@aosc.io>
Some code can be shared within different DP bridges by Analogix.
Extract them to analogix_dp.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/Makefile | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +----------------
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 173 +++++++++++++++++++++
.../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 3 +
4 files changed, 178 insertions(+), 146 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index 6fcbfd3ee560..7623b9b80167 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
-analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
+analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.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/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index c09aaf93ae1b..f36ae51c641d 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_dp_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..d6016f789d80
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -0,0 +1,174 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on anx7808 driver obtained from chromeos with copyright:
+ * Copyright(c) 2013, Google Inc.
+ *
+ */
+#include <linux/regmap.h>
+
+#include <drm/drm.h>
+#include <drm/drm_dp_helper.h>
+#include <drm/drm_print.h>
+
+#include "analogix-i2c-dptx.h"
+
+#define AUX_WAIT_TIMEOUT_MS 15
+#define AUX_CH_BUFFER_SIZE 16
+
+static int anx_i2c_dp_clear_bits(struct regmap *map, u8 reg, u8 mask)
+{
+ return regmap_update_bits(map, reg, mask, 0);
+}
+
+static bool anx_dp_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_dp_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_dp_aux_op_finished(map_dptx)) {
+ if (time_after(jiffies, timeout)) {
+ if (!anx_dp_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_dp_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_dp_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_dp_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_dp_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_i2c_dp_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG,
+ SP_ADDR_ONLY);
+ if (err)
+ return err;
+
+ return msg->size;
+}
+EXPORT_SYMBOL_GPL(anx_dp_aux_transfer);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
index 5a54c6d86428..30436c88f181 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -253,4 +253,7 @@
/* DP AUX Buffer Data Registers */
#define SP_DP_BUF_DATA0_REG 0xf0
+ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
+ struct drm_dp_aux_msg *msg);
+
#endif
--
2.16.4
_______________________________________________
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] 90+ messages in thread
* [PATCH v2 4/7] drm/bridge: Prepare Analogix anx6345 support
2019-06-04 12:21 ` Torsten Duwe
@ 2019-06-04 12:22 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
Add bit definitions required for the anx6345 and add a
sanity check in anx_dp_aux_transfer.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 8 ++++++++
drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h | 3 +++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
index d6016f789d80..e9d2ed4d410d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -124,7 +124,7 @@ ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
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 30436c88f181..95ab89eecc60 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -83,7 +83,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)
@@ -128,6 +132,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
@@ -141,6 +148,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 f48293f86f9d..e3391a50b5d1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -188,6 +188,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.16.4
^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 4/7] drm/bridge: Prepare Analogix anx6345 support
@ 2019-06-04 12:22 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:22 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
Add bit definitions required for the anx6345 and add a
sanity check in anx_dp_aux_transfer.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 8 ++++++++
drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h | 3 +++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
index d6016f789d80..e9d2ed4d410d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
@@ -124,7 +124,7 @@ ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
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 30436c88f181..95ab89eecc60 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
@@ -83,7 +83,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)
@@ -128,6 +132,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
@@ -141,6 +148,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 f48293f86f9d..e3391a50b5d1 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
@@ -188,6 +188,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.16.4
_______________________________________________
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] 90+ messages in thread
* [PATCH v2 5/7] drm/bridge: Add Analogix anx6345 support
2019-06-04 12:21 ` Torsten Duwe
@ 2019-06-04 12:23 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:23 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
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>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/Kconfig | 12 +
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 814 +++++++++++++++++++++
3 files changed, 827 insertions(+)
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 704fb0f41dc3..cd89e238b93e 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,6 +1,18 @@
# SPDX-License-Identifier: GPL-2.0-only
+config DRM_ANALOGIX_ANX6345
+ tristate "Analogix ANX6345 bridge"
+ select DRM_ANALOGIX_DP
+ 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
select DRM_KMS_HELPER
select REGMAP_I2C
help
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index 7623b9b80167..97669b374098 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o 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
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..ae222f9f6586
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -0,0 +1,814 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor.
+ * Copyright(c) 2017, Icenowy Zheng <icenowy@aosc.io>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on anx7808 driver obtained from chromeos with copyright:
+ * Copyright(c) 2013, Google Inc.
+ *
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/types.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 <drm/drm_print.h>
+#include <drm/drm_probe_helper.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 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 {
+ 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 regulator *dvdd12;
+ struct regulator *dvdd25;
+ struct gpio_desc *gpiod_reset;
+ struct mutex lock; /* protect EDID access */
+
+ /* 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_dp_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: colordepth is hardcoded for 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;
+
+ return 0;
+}
+
+static void anx6345_poweron(struct anx6345 *anx6345)
+{
+ int err;
+
+ /* Ensure reset is asserted before starting power on sequence */
+ gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
+ usleep_range(1000, 2000);
+
+ err = regulator_enable(anx6345->dvdd12);
+ if (err) {
+ DRM_ERROR("Failed to enable dvdd12 regulator: %d\n",
+ err);
+ return;
+ }
+
+ /* T1 - delay between VDD12 and VDD25 should be 0-2ms */
+ usleep_range(1000, 2000);
+
+ err = regulator_enable(anx6345->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to enable dvdd25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ /* T2 - delay between RESETN and all power rail stable,
+ * should be 2-5ms
+ */
+ usleep_range(2000, 5000);
+
+ gpiod_set_value_cansleep(anx6345->gpiod_reset, 0);
+
+ /* 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);
+
+ if (anx6345->panel)
+ drm_panel_prepare(anx6345->panel);
+
+ anx6345->powered = true;
+}
+
+static void anx6345_poweroff(struct anx6345 *anx6345)
+{
+ int err;
+
+ gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
+ usleep_range(1000, 2000);
+
+ if (anx6345->panel)
+ drm_panel_unprepare(anx6345->panel);
+
+ err = regulator_disable(anx6345->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to disable dvdd25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(5000, 10000);
+
+ err = regulator_disable(anx6345->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 eDP transmitter initialization: %d\n", err);
+ anx6345_poweroff(anx6345);
+ return err;
+ }
+
+ err = anx6345_dp_link_training(anx6345);
+ if (err) {
+ DRM_ERROR("Failed link training: %d\n", err);
+ anx6345_poweroff(anx6345);
+ return err;
+ }
+
+ /*
+ * 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;
+}
+
+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;
+ bool power_off = false;
+
+ mutex_lock(&anx6345->lock);
+
+ if (!anx6345->edid) {
+ if (!anx6345->powered) {
+ anx6345_poweron(anx6345);
+ power_off = true;
+ }
+
+ 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:
+ if (power_off)
+ anx6345_poweroff(anx6345);
+
+ mutex_unlock(&anx6345->lock);
+
+ if (!num_modes && 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 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,
+ .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 enum drm_mode_status
+anx6345_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode)
+{
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ return MODE_NO_INTERLACE;
+
+ /* Max 1200p at 5.4 Ghz, one lane */
+ if (mode->clock > 154000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+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);
+
+ if (anx6345->powered)
+ anx6345_poweroff(anx6345);
+}
+
+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_valid = anx6345_bridge_mode_valid,
+ .disable = anx6345_bridge_disable,
+ .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,
+ .cache_type = REGCACHE_NONE,
+};
+
+static const u16 anx6345_chipid_list[] = {
+ 0x6345,
+};
+
+static bool anx6345_get_chip_id(struct anx6345 *anx6345)
+{
+ unsigned int i, idl, idh, version;
+
+ if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG, &idl))
+ return false;
+
+ if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG, &idh))
+ return false;
+
+ anx6345->chipid = (u8)idl | ((u8)idh << 8);
+
+ if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG,
+ &version))
+ return false;
+
+ 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);
+ return true;
+ }
+ }
+
+ DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n",
+ anx6345->chipid, version);
+
+ return false;
+}
+
+static int anx6345_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct anx6345 *anx6345;
+ struct device *dev;
+ int i, err;
+
+ anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL);
+ if (!anx6345)
+ return -ENOMEM;
+
+ mutex_init(&anx6345->lock);
+
+ anx6345->bridge.of_node = client->dev.of_node;
+
+ anx6345->client = client;
+ i2c_set_clientdata(client, anx6345);
+
+ dev = &anx6345->client->dev;
+
+ 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");
+
+ /* 1.2V digital core power regulator */
+ anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply");
+ if (IS_ERR(anx6345->dvdd12)) {
+ DRM_ERROR("dvdd12-supply not found\n");
+ return PTR_ERR(anx6345->dvdd12);
+ }
+
+ /* 2.5V digital core power regulator */
+ anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
+ if (IS_ERR(anx6345->dvdd25)) {
+ DRM_ERROR("dvdd25-supply not found\n");
+ return PTR_ERR(anx6345->dvdd25);
+ }
+
+ /* GPIO for chip reset */
+ anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(anx6345->gpiod_reset)) {
+ DRM_ERROR("Reset gpio not found\n");
+ return PTR_ERR(anx6345->gpiod_reset);
+ }
+
+ /* 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);
+ if (anx6345_get_chip_id(anx6345)) {
+ anx6345->bridge.funcs = &anx6345_bridge_funcs;
+ drm_bridge_add(&anx6345->bridge);
+
+ return 0;
+ } else {
+ anx6345_poweroff(anx6345);
+ err = -ENODEV;
+ }
+
+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);
+
+ mutex_destroy(&anx6345->lock);
+
+ 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("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
+MODULE_LICENSE("GPL v2");
--
2.16.4
^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 5/7] drm/bridge: Add Analogix anx6345 support
@ 2019-06-04 12:23 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:23 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
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>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
drivers/gpu/drm/bridge/analogix/Kconfig | 12 +
drivers/gpu/drm/bridge/analogix/Makefile | 1 +
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 814 +++++++++++++++++++++
3 files changed, 827 insertions(+)
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 704fb0f41dc3..cd89e238b93e 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -1,6 +1,18 @@
# SPDX-License-Identifier: GPL-2.0-only
+config DRM_ANALOGIX_ANX6345
+ tristate "Analogix ANX6345 bridge"
+ select DRM_ANALOGIX_DP
+ 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
select DRM_KMS_HELPER
select REGMAP_I2C
help
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
index 7623b9b80167..97669b374098 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o 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
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..ae222f9f6586
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -0,0 +1,814 @@
+/*
+ * Copyright(c) 2016, Analogix Semiconductor.
+ * Copyright(c) 2017, Icenowy Zheng <icenowy@aosc.io>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Based on anx7808 driver obtained from chromeos with copyright:
+ * Copyright(c) 2013, Google Inc.
+ *
+ */
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/types.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 <drm/drm_print.h>
+#include <drm/drm_probe_helper.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 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 {
+ 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 regulator *dvdd12;
+ struct regulator *dvdd25;
+ struct gpio_desc *gpiod_reset;
+ struct mutex lock; /* protect EDID access */
+
+ /* 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_dp_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: colordepth is hardcoded for 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;
+
+ return 0;
+}
+
+static void anx6345_poweron(struct anx6345 *anx6345)
+{
+ int err;
+
+ /* Ensure reset is asserted before starting power on sequence */
+ gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
+ usleep_range(1000, 2000);
+
+ err = regulator_enable(anx6345->dvdd12);
+ if (err) {
+ DRM_ERROR("Failed to enable dvdd12 regulator: %d\n",
+ err);
+ return;
+ }
+
+ /* T1 - delay between VDD12 and VDD25 should be 0-2ms */
+ usleep_range(1000, 2000);
+
+ err = regulator_enable(anx6345->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to enable dvdd25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ /* T2 - delay between RESETN and all power rail stable,
+ * should be 2-5ms
+ */
+ usleep_range(2000, 5000);
+
+ gpiod_set_value_cansleep(anx6345->gpiod_reset, 0);
+
+ /* 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);
+
+ if (anx6345->panel)
+ drm_panel_prepare(anx6345->panel);
+
+ anx6345->powered = true;
+}
+
+static void anx6345_poweroff(struct anx6345 *anx6345)
+{
+ int err;
+
+ gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
+ usleep_range(1000, 2000);
+
+ if (anx6345->panel)
+ drm_panel_unprepare(anx6345->panel);
+
+ err = regulator_disable(anx6345->dvdd25);
+ if (err) {
+ DRM_ERROR("Failed to disable dvdd25 regulator: %d\n",
+ err);
+ return;
+ }
+
+ usleep_range(5000, 10000);
+
+ err = regulator_disable(anx6345->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 eDP transmitter initialization: %d\n", err);
+ anx6345_poweroff(anx6345);
+ return err;
+ }
+
+ err = anx6345_dp_link_training(anx6345);
+ if (err) {
+ DRM_ERROR("Failed link training: %d\n", err);
+ anx6345_poweroff(anx6345);
+ return err;
+ }
+
+ /*
+ * 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;
+}
+
+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;
+ bool power_off = false;
+
+ mutex_lock(&anx6345->lock);
+
+ if (!anx6345->edid) {
+ if (!anx6345->powered) {
+ anx6345_poweron(anx6345);
+ power_off = true;
+ }
+
+ 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:
+ if (power_off)
+ anx6345_poweroff(anx6345);
+
+ mutex_unlock(&anx6345->lock);
+
+ if (!num_modes && 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 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,
+ .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 enum drm_mode_status
+anx6345_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode)
+{
+ if (mode->flags & DRM_MODE_FLAG_INTERLACE)
+ return MODE_NO_INTERLACE;
+
+ /* Max 1200p at 5.4 Ghz, one lane */
+ if (mode->clock > 154000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+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);
+
+ if (anx6345->powered)
+ anx6345_poweroff(anx6345);
+}
+
+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_valid = anx6345_bridge_mode_valid,
+ .disable = anx6345_bridge_disable,
+ .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,
+ .cache_type = REGCACHE_NONE,
+};
+
+static const u16 anx6345_chipid_list[] = {
+ 0x6345,
+};
+
+static bool anx6345_get_chip_id(struct anx6345 *anx6345)
+{
+ unsigned int i, idl, idh, version;
+
+ if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG, &idl))
+ return false;
+
+ if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG, &idh))
+ return false;
+
+ anx6345->chipid = (u8)idl | ((u8)idh << 8);
+
+ if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG,
+ &version))
+ return false;
+
+ 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);
+ return true;
+ }
+ }
+
+ DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n",
+ anx6345->chipid, version);
+
+ return false;
+}
+
+static int anx6345_i2c_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct anx6345 *anx6345;
+ struct device *dev;
+ int i, err;
+
+ anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL);
+ if (!anx6345)
+ return -ENOMEM;
+
+ mutex_init(&anx6345->lock);
+
+ anx6345->bridge.of_node = client->dev.of_node;
+
+ anx6345->client = client;
+ i2c_set_clientdata(client, anx6345);
+
+ dev = &anx6345->client->dev;
+
+ 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");
+
+ /* 1.2V digital core power regulator */
+ anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply");
+ if (IS_ERR(anx6345->dvdd12)) {
+ DRM_ERROR("dvdd12-supply not found\n");
+ return PTR_ERR(anx6345->dvdd12);
+ }
+
+ /* 2.5V digital core power regulator */
+ anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
+ if (IS_ERR(anx6345->dvdd25)) {
+ DRM_ERROR("dvdd25-supply not found\n");
+ return PTR_ERR(anx6345->dvdd25);
+ }
+
+ /* GPIO for chip reset */
+ anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(anx6345->gpiod_reset)) {
+ DRM_ERROR("Reset gpio not found\n");
+ return PTR_ERR(anx6345->gpiod_reset);
+ }
+
+ /* 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);
+ if (anx6345_get_chip_id(anx6345)) {
+ anx6345->bridge.funcs = &anx6345_bridge_funcs;
+ drm_bridge_add(&anx6345->bridge);
+
+ return 0;
+ } else {
+ anx6345_poweroff(anx6345);
+ err = -ENODEV;
+ }
+
+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);
+
+ mutex_destroy(&anx6345->lock);
+
+ 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("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
+MODULE_LICENSE("GPL v2");
--
2.16.4
_______________________________________________
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] 90+ messages in thread
* [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
2019-06-04 12:21 ` Torsten Duwe
@ 2019-06-04 12:23 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:23 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
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>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Torsten Duwe <duwe@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../devicetree/bindings/display/bridge/anx6345.txt | 57 ++++++++++++++++++++++
1 file changed, 57 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..bd63f6ac107e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
@@ -0,0 +1,57 @@
+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
+ - dvdd12-supply : Regulator for 1.2V digital core power.
+ - dvdd25-supply : Regulator for 2.5V digital core power.
+ - Video port for LVTTL input, using the DT bindings defined in [1].
+
+Optional properties:
+
+ - Video port for eDP output (panel or connector) 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_LOW>; /* 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.16.4
^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
@ 2019-06-04 12:23 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:23 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
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>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Torsten Duwe <duwe@suse.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
.../devicetree/bindings/display/bridge/anx6345.txt | 57 ++++++++++++++++++++++
1 file changed, 57 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..bd63f6ac107e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
@@ -0,0 +1,57 @@
+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
+ - dvdd12-supply : Regulator for 1.2V digital core power.
+ - dvdd25-supply : Regulator for 2.5V digital core power.
+ - Video port for LVTTL input, using the DT bindings defined in [1].
+
+Optional properties:
+
+ - Video port for eDP output (panel or connector) 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_LOW>; /* 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.16.4
_______________________________________________
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] 90+ messages in thread
* [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-04 12:21 ` Torsten Duwe
@ 2019-06-04 12:23 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:23 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus. eDP output goes
to an Innolux N116BGE panel.
Enable it in the device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
.../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -65,6 +65,21 @@
};
};
+ panel: panel {
+ compatible ="innolux,n116bge", "simple-panel";
+ status = "okay";
+ power-supply = <®_dcdc1>;
+ backlight = <&backlight>;
+
+ ports {
+ panel_in: port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&anx6345_out>;
+ };
+ };
+ };
+ };
+
reg_usb1_vbus: usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -81,20 +96,48 @@
};
};
+&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_LOW>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_dldo3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ anx6345_in: endpoint {
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+ port@1 {
+ anx6345_out: endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
+&mixer0 {
+ status = "okay";
};
&mmc0 {
@@ -279,6 +322,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>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.16.4
^ permalink raw reply related [flat|nested] 90+ messages in thread
* [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-04 12:23 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-04 12:23 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus. eDP output goes
to an Innolux N116BGE panel.
Enable it in the device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Torsten Duwe <duwe@suse.de>
---
.../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
@@ -65,6 +65,21 @@
};
};
+ panel: panel {
+ compatible ="innolux,n116bge", "simple-panel";
+ status = "okay";
+ power-supply = <®_dcdc1>;
+ backlight = <&backlight>;
+
+ ports {
+ panel_in: port {
+ panel_in_edp: endpoint {
+ remote-endpoint = <&anx6345_out>;
+ };
+ };
+ };
+ };
+
reg_usb1_vbus: usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -81,20 +96,48 @@
};
};
+&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_LOW>; /* PD24 */
+ dvdd25-supply = <®_dldo2>;
+ dvdd12-supply = <®_dldo3>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ anx6345_in: endpoint {
+ remote-endpoint = <&tcon0_out_anx6345>;
+ };
+ };
+ port@1 {
+ anx6345_out: endpoint {
+ remote-endpoint = <&panel_in_edp>;
+ };
+ };
+ };
+ };
+};
+
+&mixer0 {
+ status = "okay";
};
&mmc0 {
@@ -279,6 +322,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>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.16.4
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-04 12:23 ` Torsten Duwe
(?)
@ 2019-06-04 15:08 ` Vasily Khoruzhick
-1 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-06-04 15:08 UTC (permalink / raw)
To: Torsten Duwe
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Harald Geyer,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
>
> Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus. eDP output goes
> to an Innolux N116BGE panel.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -65,6 +65,21 @@
> };
> };
>
> + panel: panel {
> + compatible ="innolux,n116bge", "simple-panel";
It's still "simple-panel". I believe I already mentioned that Rob
asked it to be edp-connector.
> + status = "okay";
> + power-supply = <®_dcdc1>;
> + backlight = <&backlight>;
> +
> + ports {
> + panel_in: port {
> + panel_in_edp: endpoint {
> + remote-endpoint = <&anx6345_out>;
> + };
> + };
> + };
> + };
> +
> reg_usb1_vbus: usb1-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb1-vbus";
> @@ -81,20 +96,48 @@
> };
> };
>
> +&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_LOW>; /* PD24 */
> + dvdd25-supply = <®_dldo2>;
> + dvdd12-supply = <®_dldo3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + anx6345_in: endpoint {
> + remote-endpoint = <&tcon0_out_anx6345>;
> + };
> + };
> + port@1 {
> + anx6345_out: endpoint {
> + remote-endpoint = <&panel_in_edp>;
> + };
> + };
> + };
> + };
> +};
> +
> +&mixer0 {
> + status = "okay";
> };
>
> &mmc0 {
> @@ -279,6 +322,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>;
> + };
> +};
> +
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pb_pins>;
> --
> 2.16.4
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-04 15:08 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-06-04 15:08 UTC (permalink / raw)
To: Torsten Duwe
Cc: Mark Rutland, devicetree, Maxime Ripard, Greg Kroah-Hartman,
linux-kernel, dri-devel, David Airlie, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Harald Geyer, Sean Paul,
Thomas Gleixner, arm-linux, Icenowy Zheng
On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
>
> Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus. eDP output goes
> to an Innolux N116BGE panel.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -65,6 +65,21 @@
> };
> };
>
> + panel: panel {
> + compatible ="innolux,n116bge", "simple-panel";
It's still "simple-panel". I believe I already mentioned that Rob
asked it to be edp-connector.
> + status = "okay";
> + power-supply = <®_dcdc1>;
> + backlight = <&backlight>;
> +
> + ports {
> + panel_in: port {
> + panel_in_edp: endpoint {
> + remote-endpoint = <&anx6345_out>;
> + };
> + };
> + };
> + };
> +
> reg_usb1_vbus: usb1-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb1-vbus";
> @@ -81,20 +96,48 @@
> };
> };
>
> +&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_LOW>; /* PD24 */
> + dvdd25-supply = <®_dldo2>;
> + dvdd12-supply = <®_dldo3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + anx6345_in: endpoint {
> + remote-endpoint = <&tcon0_out_anx6345>;
> + };
> + };
> + port@1 {
> + anx6345_out: endpoint {
> + remote-endpoint = <&panel_in_edp>;
> + };
> + };
> + };
> + };
> +};
> +
> +&mixer0 {
> + status = "okay";
> };
>
> &mmc0 {
> @@ -279,6 +322,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>;
> + };
> +};
> +
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pb_pins>;
> --
> 2.16.4
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-04 15:08 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-06-04 15:08 UTC (permalink / raw)
To: Torsten Duwe
Cc: Mark Rutland, devicetree, Andrzej Hajda, Maxime Ripard,
Greg Kroah-Hartman, linux-kernel, dri-devel, David Airlie,
Chen-Yu Tsai, Rob Herring, Thierry Reding, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Sean Paul, Thomas Gleixner,
arm-linux, Icenowy Zheng
On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
>
> Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus. eDP output goes
> to an Innolux N116BGE panel.
>
> Enable it in the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> @@ -65,6 +65,21 @@
> };
> };
>
> + panel: panel {
> + compatible ="innolux,n116bge", "simple-panel";
It's still "simple-panel". I believe I already mentioned that Rob
asked it to be edp-connector.
> + status = "okay";
> + power-supply = <®_dcdc1>;
> + backlight = <&backlight>;
> +
> + ports {
> + panel_in: port {
> + panel_in_edp: endpoint {
> + remote-endpoint = <&anx6345_out>;
> + };
> + };
> + };
> + };
> +
> reg_usb1_vbus: usb1-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb1-vbus";
> @@ -81,20 +96,48 @@
> };
> };
>
> +&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_LOW>; /* PD24 */
> + dvdd25-supply = <®_dldo2>;
> + dvdd12-supply = <®_dldo3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + anx6345_in: endpoint {
> + remote-endpoint = <&tcon0_out_anx6345>;
> + };
> + };
> + port@1 {
> + anx6345_out: endpoint {
> + remote-endpoint = <&panel_in_edp>;
> + };
> + };
> + };
> + };
> +};
> +
> +&mixer0 {
> + status = "okay";
> };
>
> &mmc0 {
> @@ -279,6 +322,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>;
> + };
> +};
> +
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pb_pins>;
> --
> 2.16.4
>
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-04 15:08 ` Vasily Khoruzhick
@ 2019-06-05 10:13 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-05 10:13 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Harald Geyer,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> >
> > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > to an Innolux N116BGE panel.
> >
> > Enable it in the device tree.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > ---
> > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > @@ -65,6 +65,21 @@
> > };
> > };
> >
> > + panel: panel {
> > + compatible ="innolux,n116bge", "simple-panel";
>
> It's still "simple-panel". I believe I already mentioned that Rob
> asked it to be edp-connector.
>
For which there are neither bindings nor drivers.
Is anybody seriously proposing to hold back support for existing
(open source!) hardware in favour of an *imaginable* *possibly* better
solution? Especially when this exact line is already used in some other places?
(there's a space missing btw...)
I'm more than glad to follow any constructive improvements towards better
modularity. However there were none so far, and on top of that, it's a laptop.
I see little advantage in mentioning an internal connector when the panel
connected is always the same.
FWIW, Rob should also have received these patches.
Torsten
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-05 10:13 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-05 10:13 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Andrzej Hajda, Maxime Ripard,
Greg Kroah-Hartman, linux-kernel, dri-devel, David Airlie,
Chen-Yu Tsai, Rob Herring, Thierry Reding, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Sean Paul, Thomas Gleixner,
arm-linux, Icenowy Zheng
On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> >
> > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > to an Innolux N116BGE panel.
> >
> > Enable it in the device tree.
> >
> > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > ---
> > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > @@ -65,6 +65,21 @@
> > };
> > };
> >
> > + panel: panel {
> > + compatible ="innolux,n116bge", "simple-panel";
>
> It's still "simple-panel". I believe I already mentioned that Rob
> asked it to be edp-connector.
>
For which there are neither bindings nor drivers.
Is anybody seriously proposing to hold back support for existing
(open source!) hardware in favour of an *imaginable* *possibly* better
solution? Especially when this exact line is already used in some other places?
(there's a space missing btw...)
I'm more than glad to follow any constructive improvements towards better
modularity. However there were none so far, and on top of that, it's a laptop.
I see little advantage in mentioning an internal connector when the panel
connected is always the same.
FWIW, Rob should also have received these patches.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-05 10:13 ` Torsten Duwe
@ 2019-06-05 12:02 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-05 12:02 UTC (permalink / raw)
To: Torsten Duwe
Cc: Vasily Khoruzhick, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Andrzej Hajda,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Harald Geyer,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]
On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > >
> > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > to an Innolux N116BGE panel.
> > >
> > > Enable it in the device tree.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > ---
> > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > @@ -65,6 +65,21 @@
> > > };
> > > };
> > >
> > > + panel: panel {
> > > + compatible ="innolux,n116bge", "simple-panel";
> >
> > It's still "simple-panel". I believe I already mentioned that Rob
> > asked it to be edp-connector.
>
> For which there are neither bindings nor drivers.
>
> Is anybody seriously proposing to hold back support for existing
> (open source!) hardware in favour of an *imaginable* *possibly*
> better solution? Especially when this exact line is already used in
> some other places? (there's a space missing btw...)
It's non-existent and imaginable only because you've been ignoring
everyone that said that you should do it. So it's self-inflicted,
really.
And the DT is considered an ABI, so yeah, we will witheld everything
that doesn't fit what we would like. Your point of view is that it's
more work and for no particular benefit, ours is that it's a
short-term pain for a long-term gain, and the benefits will be in the
maintainance cost.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-05 12:02 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-05 12:02 UTC (permalink / raw)
To: Torsten Duwe
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Andrzej Hajda, Chen-Yu Tsai,
Rob Herring, Thierry Reding, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Sean Paul, Thomas Gleixner, arm-linux,
Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 2122 bytes --]
On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > >
> > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > to an Innolux N116BGE panel.
> > >
> > > Enable it in the device tree.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > ---
> > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > @@ -65,6 +65,21 @@
> > > };
> > > };
> > >
> > > + panel: panel {
> > > + compatible ="innolux,n116bge", "simple-panel";
> >
> > It's still "simple-panel". I believe I already mentioned that Rob
> > asked it to be edp-connector.
>
> For which there are neither bindings nor drivers.
>
> Is anybody seriously proposing to hold back support for existing
> (open source!) hardware in favour of an *imaginable* *possibly*
> better solution? Especially when this exact line is already used in
> some other places? (there's a space missing btw...)
It's non-existent and imaginable only because you've been ignoring
everyone that said that you should do it. So it's self-inflicted,
really.
And the DT is considered an ABI, so yeah, we will witheld everything
that doesn't fit what we would like. Your point of view is that it's
more work and for no particular benefit, ours is that it's a
short-term pain for a long-term gain, and the benefits will be in the
maintainance cost.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-05 12:02 ` Maxime Ripard
(?)
@ 2019-06-06 13:59 ` Harald Geyer
-1 siblings, 0 replies; 90+ messages in thread
From: Harald Geyer @ 2019-06-06 13:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Torsten Duwe, Vasily Khoruzhick, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
Guys, this discussion is getting heated for no reason. Let's put
personal frustrations aside and discuss the issue on its merits:
Maxime Ripard writes:
> On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > > >
> > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > > to an Innolux N116BGE panel.
> > > >
> > > > Enable it in the device tree.
> > > >
> > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > > ---
> > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > @@ -65,6 +65,21 @@
> > > > };
> > > > };
> > > >
> > > > + panel: panel {
> > > > + compatible ="innolux,n116bge", "simple-panel";
> > >
> > > It's still "simple-panel". I believe I already mentioned that Rob
> > > asked it to be edp-connector.
Actually just dropping the "simple-panel" compatible would be a poor
choice. Even if "edp-connector" is specified as binding and implemented in a
driver, there are older kernel versions and other operating systems to
keep in mind. If the HW works with "simple-panel" driver satisfactorily,
we should definitely keep the compatible as a fall back for cases where
the edp-connector driver is unavailable.
If think valid compatible properties would be:
compatible = "innolux,n116bge", "simple-panel";
compatible = "edp-connector", "simple-panel";
compatible = "innolux,n116bge", "edp-connector", "simple-panel";
compatible = "edp-connector", "innolux,n116bge", "simple-panel";
I can't make up my mind which one I prefere. However neither of these
variants requires actually implmenting an edp-connector driver. And each
of these variants is clearly preferable to shipping DTs without
description of the panel at all and complies with bindings after adding
a stub for "edp-connector".
> And the DT is considered an ABI, so yeah, we will witheld everything
> that doesn't fit what we would like.
I fail to see how the patch in discussion adds new ABI. While I understand
the need to pester contributors for more work, outright blocking DTs, that
properly describe the HW and comply with existing bindings, seems a
bit unreasonable. (Assuming there are no other issues of course.)
Also note that the innolux,n116bge binding suggestes using simple-panel
as fallback.
HTH,
Harald
--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-06 13:59 ` Harald Geyer
0 siblings, 0 replies; 90+ messages in thread
From: Harald Geyer @ 2019-06-06 13:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
Guys, this discussion is getting heated for no reason. Let's put
personal frustrations aside and discuss the issue on its merits:
Maxime Ripard writes:
> On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > > >
> > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > > to an Innolux N116BGE panel.
> > > >
> > > > Enable it in the device tree.
> > > >
> > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > > ---
> > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > @@ -65,6 +65,21 @@
> > > > };
> > > > };
> > > >
> > > > + panel: panel {
> > > > + compatible ="innolux,n116bge", "simple-panel";
> > >
> > > It's still "simple-panel". I believe I already mentioned that Rob
> > > asked it to be edp-connector.
Actually just dropping the "simple-panel" compatible would be a poor
choice. Even if "edp-connector" is specified as binding and implemented in a
driver, there are older kernel versions and other operating systems to
keep in mind. If the HW works with "simple-panel" driver satisfactorily,
we should definitely keep the compatible as a fall back for cases where
the edp-connector driver is unavailable.
If think valid compatible properties would be:
compatible = "innolux,n116bge", "simple-panel";
compatible = "edp-connector", "simple-panel";
compatible = "innolux,n116bge", "edp-connector", "simple-panel";
compatible = "edp-connector", "innolux,n116bge", "simple-panel";
I can't make up my mind which one I prefere. However neither of these
variants requires actually implmenting an edp-connector driver. And each
of these variants is clearly preferable to shipping DTs without
description of the panel at all and complies with bindings after adding
a stub for "edp-connector".
> And the DT is considered an ABI, so yeah, we will witheld everything
> that doesn't fit what we would like.
I fail to see how the patch in discussion adds new ABI. While I understand
the need to pester contributors for more work, outright blocking DTs, that
properly describe the HW and comply with existing bindings, seems a
bit unreasonable. (Assuming there are no other issues of course.)
Also note that the innolux,n116bge binding suggestes using simple-panel
as fallback.
HTH,
Harald
--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-06 13:59 ` Harald Geyer
0 siblings, 0 replies; 90+ messages in thread
From: Harald Geyer @ 2019-06-06 13:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
Guys, this discussion is getting heated for no reason. Let's put
personal frustrations aside and discuss the issue on its merits:
Maxime Ripard writes:
> On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > > >
> > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > > to an Innolux N116BGE panel.
> > > >
> > > > Enable it in the device tree.
> > > >
> > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > > ---
> > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > @@ -65,6 +65,21 @@
> > > > };
> > > > };
> > > >
> > > > + panel: panel {
> > > > + compatible ="innolux,n116bge", "simple-panel";
> > >
> > > It's still "simple-panel". I believe I already mentioned that Rob
> > > asked it to be edp-connector.
Actually just dropping the "simple-panel" compatible would be a poor
choice. Even if "edp-connector" is specified as binding and implemented in a
driver, there are older kernel versions and other operating systems to
keep in mind. If the HW works with "simple-panel" driver satisfactorily,
we should definitely keep the compatible as a fall back for cases where
the edp-connector driver is unavailable.
If think valid compatible properties would be:
compatible = "innolux,n116bge", "simple-panel";
compatible = "edp-connector", "simple-panel";
compatible = "innolux,n116bge", "edp-connector", "simple-panel";
compatible = "edp-connector", "innolux,n116bge", "simple-panel";
I can't make up my mind which one I prefere. However neither of these
variants requires actually implmenting an edp-connector driver. And each
of these variants is clearly preferable to shipping DTs without
description of the panel at all and complies with bindings after adding
a stub for "edp-connector".
> And the DT is considered an ABI, so yeah, we will witheld everything
> that doesn't fit what we would like.
I fail to see how the patch in discussion adds new ABI. While I understand
the need to pester contributors for more work, outright blocking DTs, that
properly describe the HW and comply with existing bindings, seems a
bit unreasonable. (Assuming there are no other issues of course.)
Also note that the innolux,n116bge binding suggestes using simple-panel
as fallback.
HTH,
Harald
--
If you want to support my work:
see http://friends.ccbib.org/harald/supporting/
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-06 13:59 ` Harald Geyer
(?)
@ 2019-06-07 6:28 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-07 6:28 UTC (permalink / raw)
To: Harald Geyer
Cc: Torsten Duwe, Vasily Khoruzhick, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> Guys, this discussion is getting heated for no reason. Let's put
> personal frustrations aside and discuss the issue on its merits:
>
> Maxime Ripard writes:
> > On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > > > >
> > > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > > > to an Innolux N116BGE panel.
> > > > >
> > > > > Enable it in the device tree.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > > > ---
> > > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > > @@ -65,6 +65,21 @@
> > > > > };
> > > > > };
> > > > >
> > > > > + panel: panel {
> > > > > + compatible ="innolux,n116bge", "simple-panel";
> > > >
> > > > It's still "simple-panel". I believe I already mentioned that Rob
> > > > asked it to be edp-connector.
>
> Actually just dropping the "simple-panel" compatible would be a poor
> choice. Even if "edp-connector" is specified as binding and implemented in a
> driver, there are older kernel versions and other operating systems to
> keep in mind.
Which older kernels? This is a new binding, adding a new driver, so if
an older kernel uses a separate driver with its own binding, good for
them, but we don't have to support it.
> If the HW works with "simple-panel" driver satisfactorily,
> we should definitely keep the compatible as a fall back for cases where
> the edp-connector driver is unavailable.
>
> If think valid compatible properties would be:
> compatible = "innolux,n116bge", "simple-panel";
> compatible = "edp-connector", "simple-panel";
A connector isn't a panel.
> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
And the innolux,n116bge is certainly not a connector either.
> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
>
> I can't make up my mind which one I prefere. However neither of these
> variants requires actually implmenting an edp-connector driver.
No-one asked to do an edp-connector driver. You should use it in your
DT, but if you want to have some code in your driver that parses the
DT directly, I'm totally fine with that.
> And each of these variants is clearly preferable to shipping DTs
> without description of the panel at all and complies with bindings
> after adding a stub for "edp-connector".
I guess you should describe why do you think it's "clear", because I'm
not sure this is obvious for everyone here. eDP allows to discover
which device is on the other side and its supported timings, just like
HDMI for example (or regular DP, for that matter). Would you think
it's clearly preferable to ship a DT with the DP/HDMI monitor
connected on the other side exposed as a panel as well?
> > And the DT is considered an ABI, so yeah, we will witheld everything
> > that doesn't fit what we would like.
>
> I fail to see how the patch in discussion adds new ABI.
The binding itself is the ABI, and we will have to support that
binding for pretty much forever.
> While I understand the need to pester contributors for more work,
> outright blocking DTs, that properly describe the HW
Properly is arguable.
> and comply with existing bindings
And that's bindings meant for another use-case.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-07 6:28 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-07 6:28 UTC (permalink / raw)
To: Harald Geyer
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Vasily Khoruzhick,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Thierry Reding, Thomas Gleixner, arm-linux, Icenowy Zheng
On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> Guys, this discussion is getting heated for no reason. Let's put
> personal frustrations aside and discuss the issue on its merits:
>
> Maxime Ripard writes:
> > On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > > > >
> > > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > > > to an Innolux N116BGE panel.
> > > > >
> > > > > Enable it in the device tree.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > > > ---
> > > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > > @@ -65,6 +65,21 @@
> > > > > };
> > > > > };
> > > > >
> > > > > + panel: panel {
> > > > > + compatible ="innolux,n116bge", "simple-panel";
> > > >
> > > > It's still "simple-panel". I believe I already mentioned that Rob
> > > > asked it to be edp-connector.
>
> Actually just dropping the "simple-panel" compatible would be a poor
> choice. Even if "edp-connector" is specified as binding and implemented in a
> driver, there are older kernel versions and other operating systems to
> keep in mind.
Which older kernels? This is a new binding, adding a new driver, so if
an older kernel uses a separate driver with its own binding, good for
them, but we don't have to support it.
> If the HW works with "simple-panel" driver satisfactorily,
> we should definitely keep the compatible as a fall back for cases where
> the edp-connector driver is unavailable.
>
> If think valid compatible properties would be:
> compatible = "innolux,n116bge", "simple-panel";
> compatible = "edp-connector", "simple-panel";
A connector isn't a panel.
> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
And the innolux,n116bge is certainly not a connector either.
> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
>
> I can't make up my mind which one I prefere. However neither of these
> variants requires actually implmenting an edp-connector driver.
No-one asked to do an edp-connector driver. You should use it in your
DT, but if you want to have some code in your driver that parses the
DT directly, I'm totally fine with that.
> And each of these variants is clearly preferable to shipping DTs
> without description of the panel at all and complies with bindings
> after adding a stub for "edp-connector".
I guess you should describe why do you think it's "clear", because I'm
not sure this is obvious for everyone here. eDP allows to discover
which device is on the other side and its supported timings, just like
HDMI for example (or regular DP, for that matter). Would you think
it's clearly preferable to ship a DT with the DP/HDMI monitor
connected on the other side exposed as a panel as well?
> > And the DT is considered an ABI, so yeah, we will witheld everything
> > that doesn't fit what we would like.
>
> I fail to see how the patch in discussion adds new ABI.
The binding itself is the ABI, and we will have to support that
binding for pretty much forever.
> While I understand the need to pester contributors for more work,
> outright blocking DTs, that properly describe the HW
Properly is arguable.
> and comply with existing bindings
And that's bindings meant for another use-case.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-07 6:28 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-07 6:28 UTC (permalink / raw)
To: Harald Geyer
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> Guys, this discussion is getting heated for no reason. Let's put
> personal frustrations aside and discuss the issue on its merits:
>
> Maxime Ripard writes:
> > On Wed, Jun 05, 2019 at 12:13:17PM +0200, Torsten Duwe wrote:
> > > On Tue, Jun 04, 2019 at 08:08:40AM -0700, Vasily Khoruzhick wrote:
> > > > On Tue, Jun 4, 2019 at 5:23 AM Torsten Duwe <duwe@lst.de> wrote:
> > > > >
> > > > > Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> > > > > the I2C controlling signals are connected to I2C0 bus. eDP output goes
> > > > > to an Innolux N116BGE panel.
> > > > >
> > > > > Enable it in the device tree.
> > > > >
> > > > > Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> > > > > Signed-off-by: Torsten Duwe <duwe@suse.de>
> > > > > ---
> > > > > .../boot/dts/allwinner/sun50i-a64-teres-i.dts | 65 ++++++++++++++++++++--
> > > > > 1 file changed, 61 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 0ec46b969a75..a0ad438b037f 100644
> > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > > > > @@ -65,6 +65,21 @@
> > > > > };
> > > > > };
> > > > >
> > > > > + panel: panel {
> > > > > + compatible ="innolux,n116bge", "simple-panel";
> > > >
> > > > It's still "simple-panel". I believe I already mentioned that Rob
> > > > asked it to be edp-connector.
>
> Actually just dropping the "simple-panel" compatible would be a poor
> choice. Even if "edp-connector" is specified as binding and implemented in a
> driver, there are older kernel versions and other operating systems to
> keep in mind.
Which older kernels? This is a new binding, adding a new driver, so if
an older kernel uses a separate driver with its own binding, good for
them, but we don't have to support it.
> If the HW works with "simple-panel" driver satisfactorily,
> we should definitely keep the compatible as a fall back for cases where
> the edp-connector driver is unavailable.
>
> If think valid compatible properties would be:
> compatible = "innolux,n116bge", "simple-panel";
> compatible = "edp-connector", "simple-panel";
A connector isn't a panel.
> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
And the innolux,n116bge is certainly not a connector either.
> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
>
> I can't make up my mind which one I prefere. However neither of these
> variants requires actually implmenting an edp-connector driver.
No-one asked to do an edp-connector driver. You should use it in your
DT, but if you want to have some code in your driver that parses the
DT directly, I'm totally fine with that.
> And each of these variants is clearly preferable to shipping DTs
> without description of the panel at all and complies with bindings
> after adding a stub for "edp-connector".
I guess you should describe why do you think it's "clear", because I'm
not sure this is obvious for everyone here. eDP allows to discover
which device is on the other side and its supported timings, just like
HDMI for example (or regular DP, for that matter). Would you think
it's clearly preferable to ship a DT with the DP/HDMI monitor
connected on the other side exposed as a panel as well?
> > And the DT is considered an ABI, so yeah, we will witheld everything
> > that doesn't fit what we would like.
>
> I fail to see how the patch in discussion adds new ABI.
The binding itself is the ABI, and we will have to support that
binding for pretty much forever.
> While I understand the need to pester contributors for more work,
> outright blocking DTs, that properly describe the HW
Properly is arguable.
> and comply with existing bindings
And that's bindings meant for another use-case.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-07 6:28 ` Maxime Ripard
@ 2019-06-07 9:40 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-07 9:40 UTC (permalink / raw)
To: Maxime Ripard
Cc: Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> >
> > If think valid compatible properties would be:
> > compatible = "innolux,n116bge", "simple-panel";
> > compatible = "edp-connector", "simple-panel";
>
> A connector isn't a panel.
>
> > compatible = "innolux,n116bge", "edp-connector", "simple-panel";
>
> And the innolux,n116bge is certainly not a connector either.
>
> > compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> >
> > I can't make up my mind which one I prefere. However neither of these
> > variants requires actually implmenting an edp-connector driver.
>
> No-one asked to do an edp-connector driver. You should use it in your
> DT, but if you want to have some code in your driver that parses the
> DT directly, I'm totally fine with that.
I must admit I fail to understand what that extra node would be good for.
Logically, the eDP far side is connected to the well-known n116bge.
Inside the laptop case it might as well be a flat ribbon cable or
soldered directly.
In good intention, that's all I wanted to express in the DT. I don't
know whether the relevant mechanical dimensions of the panel and the
connector are standardised, so whether one could in theory assemble it
with a different panel than the one it came with.
OTOH, as I checked during the discussion with anarsoul, the panel's
supply voltage is permanently connected to the main 3.3V rail.
We already agreed that the eDP output port must not neccessarily be
specified, this setup is a good example why: because the panel is
always powered, the anx6345 can always pull valid EDID data from it
so at this stage there's no need for any OS driver to reach beyond
the bridge. IIRC even the backlight got switched off for the blank
screen without.
All I wanted to say is that "there's usually an n116bge behind it";
but this is mostly redundant.
So, shall we just drop the output port specification (along with the
panel node) in order to get one step further?
> I guess you should describe why do you think it's "clear", because I'm
> not sure this is obvious for everyone here. eDP allows to discover
> which device is on the other side and its supported timings, just like
> HDMI for example (or regular DP, for that matter). Would you think
> it's clearly preferable to ship a DT with the DP/HDMI monitor
> connected on the other side exposed as a panel as well?
Well, as I wrote: "in good intention". That's the panel that comes with
the kit but it is very well detected automatically, just like you describe.
So, just leave it out?
Torsten
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-07 9:40 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-07 9:40 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Andrzej Hajda, Chen-Yu Tsai,
Rob Herring, Thierry Reding, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Sean Paul, Thomas Gleixner, arm-linux,
Icenowy Zheng
On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> >
> > If think valid compatible properties would be:
> > compatible = "innolux,n116bge", "simple-panel";
> > compatible = "edp-connector", "simple-panel";
>
> A connector isn't a panel.
>
> > compatible = "innolux,n116bge", "edp-connector", "simple-panel";
>
> And the innolux,n116bge is certainly not a connector either.
>
> > compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> >
> > I can't make up my mind which one I prefere. However neither of these
> > variants requires actually implmenting an edp-connector driver.
>
> No-one asked to do an edp-connector driver. You should use it in your
> DT, but if you want to have some code in your driver that parses the
> DT directly, I'm totally fine with that.
I must admit I fail to understand what that extra node would be good for.
Logically, the eDP far side is connected to the well-known n116bge.
Inside the laptop case it might as well be a flat ribbon cable or
soldered directly.
In good intention, that's all I wanted to express in the DT. I don't
know whether the relevant mechanical dimensions of the panel and the
connector are standardised, so whether one could in theory assemble it
with a different panel than the one it came with.
OTOH, as I checked during the discussion with anarsoul, the panel's
supply voltage is permanently connected to the main 3.3V rail.
We already agreed that the eDP output port must not neccessarily be
specified, this setup is a good example why: because the panel is
always powered, the anx6345 can always pull valid EDID data from it
so at this stage there's no need for any OS driver to reach beyond
the bridge. IIRC even the backlight got switched off for the blank
screen without.
All I wanted to say is that "there's usually an n116bge behind it";
but this is mostly redundant.
So, shall we just drop the output port specification (along with the
panel node) in order to get one step further?
> I guess you should describe why do you think it's "clear", because I'm
> not sure this is obvious for everyone here. eDP allows to discover
> which device is on the other side and its supported timings, just like
> HDMI for example (or regular DP, for that matter). Would you think
> it's clearly preferable to ship a DT with the DP/HDMI monitor
> connected on the other side exposed as a panel as well?
Well, as I wrote: "in good intention". That's the panel that comes with
the kit but it is very well detected automatically, just like you describe.
So, just leave it out?
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] 90+ messages in thread
* Re: [PATCH v2 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers
2019-06-04 12:22 ` Torsten Duwe
(?)
@ 2019-06-12 7:40 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 7:40 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> 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>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 465 +--------------------
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 256 ++++++++++++
> .../drm/bridge/analogix/analogix-i2c-txcommon.h | 242 +++++++++++
> 3 files changed, 503 insertions(+), 460 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..3fbe2c3244fd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> @@ -11,13 +11,15 @@
> * GNU General Public License for more details.
> *
> */
> -
> #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 +227,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..5a54c6d86428
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -0,0 +1,256 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Please use SPDX identifiers in all new files.
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + *
> + */
> +#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..f48293f86f9d
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
> @@ -0,0 +1,242 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
ditto
With above fixed:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> + *
> + */
> +#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_ */
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers
@ 2019-06-12 7:40 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 7:40 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> 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>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 465 +--------------------
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 256 ++++++++++++
> .../drm/bridge/analogix/analogix-i2c-txcommon.h | 242 +++++++++++
> 3 files changed, 503 insertions(+), 460 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..3fbe2c3244fd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> @@ -11,13 +11,15 @@
> * GNU General Public License for more details.
> *
> */
> -
> #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 +227,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..5a54c6d86428
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -0,0 +1,256 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Please use SPDX identifiers in all new files.
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + *
> + */
> +#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..f48293f86f9d
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
> @@ -0,0 +1,242 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
ditto
With above fixed:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> + *
> + */
> +#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_ */
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers
@ 2019-06-12 7:40 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 7:40 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> 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>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h | 465 +--------------------
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 256 ++++++++++++
> .../drm/bridge/analogix/analogix-i2c-txcommon.h | 242 +++++++++++
> 3 files changed, 503 insertions(+), 460 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..3fbe2c3244fd 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.h
> @@ -11,13 +11,15 @@
> * GNU General Public License for more details.
> *
> */
> -
> #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 +227,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..5a54c6d86428
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -0,0 +1,256 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Please use SPDX identifiers in all new files.
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + *
> + */
> +#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..f48293f86f9d
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
> @@ -0,0 +1,242 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
ditto
With above fixed:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> + *
> + */
> +#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_ */
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 3/7] drm/bridge: extract some Analogix I2C DP common code
2019-06-04 12:22 ` Torsten Duwe
@ 2019-06-12 7:41 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 7:41 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Some code can be shared within different DP bridges by Analogix.
> Extract them to analogix_dp.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/Makefile | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +----------------
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 173 +++++++++++++++++++++
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 3 +
> 4 files changed, 178 insertions(+), 146 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
> index 6fcbfd3ee560..7623b9b80167 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> +analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.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/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index c09aaf93ae1b..f36ae51c641d 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_dp_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..d6016f789d80
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> @@ -0,0 +1,174 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Again spdx.
With that fixed:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + *
> + */
> +#include <linux/regmap.h>
> +
> +#include <drm/drm.h>
> +#include <drm/drm_dp_helper.h>
> +#include <drm/drm_print.h>
> +
> +#include "analogix-i2c-dptx.h"
> +
> +#define AUX_WAIT_TIMEOUT_MS 15
> +#define AUX_CH_BUFFER_SIZE 16
> +
> +static int anx_i2c_dp_clear_bits(struct regmap *map, u8 reg, u8 mask)
> +{
> + return regmap_update_bits(map, reg, mask, 0);
> +}
> +
> +static bool anx_dp_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_dp_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_dp_aux_op_finished(map_dptx)) {
> + if (time_after(jiffies, timeout)) {
> + if (!anx_dp_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_dp_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_dp_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_dp_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_dp_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_i2c_dp_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG,
> + SP_ADDR_ONLY);
> + if (err)
> + return err;
> +
> + return msg->size;
> +}
> +EXPORT_SYMBOL_GPL(anx_dp_aux_transfer);
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> index 5a54c6d86428..30436c88f181 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -253,4 +253,7 @@
> /* DP AUX Buffer Data Registers */
> #define SP_DP_BUF_DATA0_REG 0xf0
>
> +ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
> + struct drm_dp_aux_msg *msg);
> +
> #endif
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 3/7] drm/bridge: extract some Analogix I2C DP common code
@ 2019-06-12 7:41 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 7:41 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> From: Icenowy Zheng <icenowy@aosc.io>
>
> Some code can be shared within different DP bridges by Analogix.
> Extract them to analogix_dp.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/Makefile | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 146 +----------------
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 173 +++++++++++++++++++++
> .../gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 3 +
> 4 files changed, 178 insertions(+), 146 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
> index 6fcbfd3ee560..7623b9b80167 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,4 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
> +analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o analogix-i2c-dptx.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/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
> index c09aaf93ae1b..f36ae51c641d 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_dp_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..d6016f789d80
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> @@ -0,0 +1,174 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
Again spdx.
With that fixed:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + *
> + */
> +#include <linux/regmap.h>
> +
> +#include <drm/drm.h>
> +#include <drm/drm_dp_helper.h>
> +#include <drm/drm_print.h>
> +
> +#include "analogix-i2c-dptx.h"
> +
> +#define AUX_WAIT_TIMEOUT_MS 15
> +#define AUX_CH_BUFFER_SIZE 16
> +
> +static int anx_i2c_dp_clear_bits(struct regmap *map, u8 reg, u8 mask)
> +{
> + return regmap_update_bits(map, reg, mask, 0);
> +}
> +
> +static bool anx_dp_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_dp_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_dp_aux_op_finished(map_dptx)) {
> + if (time_after(jiffies, timeout)) {
> + if (!anx_dp_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_dp_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_dp_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_dp_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_dp_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_i2c_dp_clear_bits(map_dptx, SP_DP_AUX_CH_CTRL2_REG,
> + SP_ADDR_ONLY);
> + if (err)
> + return err;
> +
> + return msg->size;
> +}
> +EXPORT_SYMBOL_GPL(anx_dp_aux_transfer);
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> index 5a54c6d86428..30436c88f181 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -253,4 +253,7 @@
> /* DP AUX Buffer Data Registers */
> #define SP_DP_BUF_DATA0_REG 0xf0
>
> +ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
> + struct drm_dp_aux_msg *msg);
> +
> #endif
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 4/7] drm/bridge: Prepare Analogix anx6345 support
2019-06-04 12:22 ` Torsten Duwe
@ 2019-06-12 7:43 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 7:43 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> Add bit definitions required for the anx6345 and add a
> sanity check in anx_dp_aux_transfer.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 8 ++++++++
> drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h | 3 +++
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> index d6016f789d80..e9d2ed4d410d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> @@ -124,7 +124,7 @@ ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
> 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 30436c88f181..95ab89eecc60 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -83,7 +83,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)
>
> @@ -128,6 +132,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
>
> @@ -141,6 +148,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 f48293f86f9d..e3391a50b5d1 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
> @@ -188,6 +188,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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 4/7] drm/bridge: Prepare Analogix anx6345 support
@ 2019-06-12 7:43 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 7:43 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> Add bit definitions required for the anx6345 and add a
> sanity check in anx_dp_aux_transfer.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c | 2 +-
> drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h | 8 ++++++++
> drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h | 3 +++
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> index d6016f789d80..e9d2ed4d410d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.c
> @@ -124,7 +124,7 @@ ssize_t anx_dp_aux_transfer(struct regmap *map_dptx,
> 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 30436c88f181..95ab89eecc60 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-dptx.h
> @@ -83,7 +83,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)
>
> @@ -128,6 +132,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
>
> @@ -141,6 +148,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 f48293f86f9d..e3391a50b5d1 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-i2c-txcommon.h
> @@ -188,6 +188,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
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
2019-06-04 12:23 ` Torsten Duwe
@ 2019-06-12 8:16 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 8:16 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
On 04.06.2019 14:23, Torsten Duwe wrote:
> 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>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> .../devicetree/bindings/display/bridge/anx6345.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 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..bd63f6ac107e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
> @@ -0,0 +1,57 @@
> +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
You have not specified it's active state, since in driver's code you
named it RESETN I guess it should be active low.
> + - dvdd12-supply : Regulator for 1.2V digital core power.
> + - dvdd25-supply : Regulator for 2.5V digital core power.
> + - Video port for LVTTL input, using the DT bindings defined in [1].
Please assign port number for input (I guess 0).
> +
> +Optional properties:
> +
> + - Video port for eDP output (panel or connector) using the DT bindings
> + defined in [1].
Shouldn't it be also required?
Regards
Andrzej
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +anx6345: anx6345@38 {
> + compatible = "analogix,anx6345";
> + reg = <0x38>;
> + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* 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>;
> + };
> + };
> + };
> +};
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
@ 2019-06-12 8:16 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 8:16 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
On 04.06.2019 14:23, Torsten Duwe wrote:
> 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>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> .../devicetree/bindings/display/bridge/anx6345.txt | 57 ++++++++++++++++++++++
> 1 file changed, 57 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..bd63f6ac107e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/anx6345.txt
> @@ -0,0 +1,57 @@
> +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
You have not specified it's active state, since in driver's code you
named it RESETN I guess it should be active low.
> + - dvdd12-supply : Regulator for 1.2V digital core power.
> + - dvdd25-supply : Regulator for 2.5V digital core power.
> + - Video port for LVTTL input, using the DT bindings defined in [1].
Please assign port number for input (I guess 0).
> +
> +Optional properties:
> +
> + - Video port for eDP output (panel or connector) using the DT bindings
> + defined in [1].
Shouldn't it be also required?
Regards
Andrzej
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> +anx6345: anx6345@38 {
> + compatible = "analogix,anx6345";
> + reg = <0x38>;
> + reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* 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>;
> + };
> + };
> + };
> +};
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 5/7] drm/bridge: Add Analogix anx6345 support
2019-06-04 12:23 ` Torsten Duwe
@ 2019-06-12 9:13 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 9:13 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
On 04.06.2019 14:23, Torsten Duwe wrote:
> 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>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 12 +
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 814 +++++++++++++++++++++
> 3 files changed, 827 insertions(+)
> 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 704fb0f41dc3..cd89e238b93e 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,6 +1,18 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config DRM_ANALOGIX_ANX6345
> + tristate "Analogix ANX6345 bridge"
> + select DRM_ANALOGIX_DP
> + 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
> select DRM_KMS_HELPER
> select REGMAP_I2C
> help
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
> index 7623b9b80167..97669b374098 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o 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
> 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..ae222f9f6586
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -0,0 +1,814 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + * Copyright(c) 2017, Icenowy Zheng <icenowy@aosc.io>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
SPDX
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + *
> + */
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/types.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 <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +#include "analogix-i2c-dptx.h"
> +#include "analogix-i2c-txcommon.h"
> +
> +#define I2C_NUM_ADDRESSES 2
You can define it as ARRAY_SIZE(anx6345_i2c_addresses) - more generic.
> +#define I2C_IDX_DPTX 0
> +#define I2C_IDX_TXCOM 1
> +
> +#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 {
> + 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 regulator *dvdd12;
> + struct regulator *dvdd25;
> + struct gpio_desc *gpiod_reset;
> + struct mutex lock; /* protect EDID access */
> +
> + /* 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_dp_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;
You can use:
return regmap_read_poll_timeout(....);
> +}
> +
> +static int anx6345_tx_initialization(struct anx6345 *anx6345)
> +{
> + int err, i;
> +
> + /* FIXME: colordepth is hardcoded for 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;
> +
> + return 0;
ditto
> +}
> +
> +static void anx6345_poweron(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + /* Ensure reset is asserted before starting power on sequence */
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
With fixed devm_gpiod_get below this line can be removed.
> + usleep_range(1000, 2000);
> +
> + err = regulator_enable(anx6345->dvdd12);
> + if (err) {
> + DRM_ERROR("Failed to enable dvdd12 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + /* T1 - delay between VDD12 and VDD25 should be 0-2ms */
> + usleep_range(1000, 2000);
> +
> + err = regulator_enable(anx6345->dvdd25);
> + if (err) {
> + DRM_ERROR("Failed to enable dvdd25 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + /* T2 - delay between RESETN and all power rail stable,
> + * should be 2-5ms
> + */
> + usleep_range(2000, 5000);
> +
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 0);
> +
> + /* 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);
> +
> + if (anx6345->panel)
> + drm_panel_prepare(anx6345->panel);
> +
> + anx6345->powered = true;
> +}
> +
> +static void anx6345_poweroff(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
> + usleep_range(1000, 2000);
> +
> + if (anx6345->panel)
> + drm_panel_unprepare(anx6345->panel);
> +
> + err = regulator_disable(anx6345->dvdd25);
> + if (err) {
> + DRM_ERROR("Failed to disable dvdd25 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + usleep_range(5000, 10000);
> +
> + err = regulator_disable(anx6345->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 eDP transmitter initialization: %d\n", err);
> + anx6345_poweroff(anx6345);
> + return err;
> + }
> +
> + err = anx6345_dp_link_training(anx6345);
> + if (err) {
> + DRM_ERROR("Failed link training: %d\n", err);
> + anx6345_poweroff(anx6345);
> + return err;
> + }
> +
> + /*
> + * 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;
> +}
> +
> +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;
> + bool power_off = false;
> +
> + mutex_lock(&anx6345->lock);
> +
> + if (!anx6345->edid) {
> + if (!anx6345->powered) {
> + anx6345_poweron(anx6345);
> + power_off = true;
> + }
> +
> + 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:
> + if (power_off)
> + anx6345_poweroff(anx6345);
> +
> + mutex_unlock(&anx6345->lock);
> +
> + if (!num_modes && 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 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,
> + .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 enum drm_mode_status
> +anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return MODE_NO_INTERLACE;
> +
> + /* Max 1200p at 5.4 Ghz, one lane */
> + if (mode->clock > 154000)
> + return MODE_CLOCK_HIGH;
I wonder if you shouldn't take into account training results here, ie.
training perfrormed before validation.
> +
> + return MODE_OK;
> +}
> +
> +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);
> +
> + if (anx6345->powered)
> + anx6345_poweroff(anx6345);
> +}
> +
> +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_valid = anx6345_bridge_mode_valid,
> + .disable = anx6345_bridge_disable,
> + .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,
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +static const u16 anx6345_chipid_list[] = {
> + 0x6345,
> +};
> +
> +static bool anx6345_get_chip_id(struct anx6345 *anx6345)
> +{
> + unsigned int i, idl, idh, version;
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG, &idl))
> + return false;
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG, &idh))
> + return false;
> +
> + anx6345->chipid = (u8)idl | ((u8)idh << 8);
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG,
> + &version))
> + return false;
> +
> + 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);
> + return true;
> + }
> + }
> +
> + DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n",
> + anx6345->chipid, version);
> +
> + return false;
> +}
> +
> +static int anx6345_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct anx6345 *anx6345;
> + struct device *dev;
> + int i, err;
> +
> + anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL);
> + if (!anx6345)
> + return -ENOMEM;
> +
> + mutex_init(&anx6345->lock);
> +
> + anx6345->bridge.of_node = client->dev.of_node;
> +
> + anx6345->client = client;
> + i2c_set_clientdata(client, anx6345);
> +
> + dev = &anx6345->client->dev;
> +
> + 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");
> +
> + /* 1.2V digital core power regulator */
> + anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply");
> + if (IS_ERR(anx6345->dvdd12)) {
> + DRM_ERROR("dvdd12-supply not found\n");
> + return PTR_ERR(anx6345->dvdd12);
> + }
> +
> + /* 2.5V digital core power regulator */
> + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
> + if (IS_ERR(anx6345->dvdd25)) {
> + DRM_ERROR("dvdd25-supply not found\n");
> + return PTR_ERR(anx6345->dvdd25);
> + }
> +
> + /* GPIO for chip reset */
> + anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
Shouldn't be set to GPIOD_OUT_HIGH?
> + if (IS_ERR(anx6345->gpiod_reset)) {
> + DRM_ERROR("Reset gpio not found\n");
> + return PTR_ERR(anx6345->gpiod_reset);
> + }
> +
> + /* 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);
> + if (anx6345_get_chip_id(anx6345)) {
> + anx6345->bridge.funcs = &anx6345_bridge_funcs;
> + drm_bridge_add(&anx6345->bridge);
> +
> + return 0;
> + } else {
> + anx6345_poweroff(anx6345);
> + err = -ENODEV;
> + }
> +
> +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);
> +
> + mutex_destroy(&anx6345->lock);
> +
> + 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("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
Submitter, patch author, and module author are different, this can be
correct, but maybe somebody forgot to update some of these fields.
Regards
Andrzej
> +MODULE_LICENSE("GPL v2");
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 5/7] drm/bridge: Add Analogix anx6345 support
@ 2019-06-12 9:13 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 9:13 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
On 04.06.2019 14:23, Torsten Duwe wrote:
> 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>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 12 +
> drivers/gpu/drm/bridge/analogix/Makefile | 1 +
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 814 +++++++++++++++++++++
> 3 files changed, 827 insertions(+)
> 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 704fb0f41dc3..cd89e238b93e 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,6 +1,18 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +config DRM_ANALOGIX_ANX6345
> + tristate "Analogix ANX6345 bridge"
> + select DRM_ANALOGIX_DP
> + 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
> select DRM_KMS_HELPER
> select REGMAP_I2C
> help
> diff --git a/drivers/gpu/drm/bridge/analogix/Makefile b/drivers/gpu/drm/bridge/analogix/Makefile
> index 7623b9b80167..97669b374098 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,4 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o 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
> 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..ae222f9f6586
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -0,0 +1,814 @@
> +/*
> + * Copyright(c) 2016, Analogix Semiconductor.
> + * Copyright(c) 2017, Icenowy Zheng <icenowy@aosc.io>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
SPDX
> + *
> + * Based on anx7808 driver obtained from chromeos with copyright:
> + * Copyright(c) 2013, Google Inc.
> + *
> + */
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/types.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 <drm/drm_print.h>
> +#include <drm/drm_probe_helper.h>
> +
> +#include "analogix-i2c-dptx.h"
> +#include "analogix-i2c-txcommon.h"
> +
> +#define I2C_NUM_ADDRESSES 2
You can define it as ARRAY_SIZE(anx6345_i2c_addresses) - more generic.
> +#define I2C_IDX_DPTX 0
> +#define I2C_IDX_TXCOM 1
> +
> +#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 {
> + 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 regulator *dvdd12;
> + struct regulator *dvdd25;
> + struct gpio_desc *gpiod_reset;
> + struct mutex lock; /* protect EDID access */
> +
> + /* 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_dp_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;
You can use:
return regmap_read_poll_timeout(....);
> +}
> +
> +static int anx6345_tx_initialization(struct anx6345 *anx6345)
> +{
> + int err, i;
> +
> + /* FIXME: colordepth is hardcoded for 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;
> +
> + return 0;
ditto
> +}
> +
> +static void anx6345_poweron(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + /* Ensure reset is asserted before starting power on sequence */
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
With fixed devm_gpiod_get below this line can be removed.
> + usleep_range(1000, 2000);
> +
> + err = regulator_enable(anx6345->dvdd12);
> + if (err) {
> + DRM_ERROR("Failed to enable dvdd12 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + /* T1 - delay between VDD12 and VDD25 should be 0-2ms */
> + usleep_range(1000, 2000);
> +
> + err = regulator_enable(anx6345->dvdd25);
> + if (err) {
> + DRM_ERROR("Failed to enable dvdd25 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + /* T2 - delay between RESETN and all power rail stable,
> + * should be 2-5ms
> + */
> + usleep_range(2000, 5000);
> +
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 0);
> +
> + /* 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);
> +
> + if (anx6345->panel)
> + drm_panel_prepare(anx6345->panel);
> +
> + anx6345->powered = true;
> +}
> +
> +static void anx6345_poweroff(struct anx6345 *anx6345)
> +{
> + int err;
> +
> + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
> + usleep_range(1000, 2000);
> +
> + if (anx6345->panel)
> + drm_panel_unprepare(anx6345->panel);
> +
> + err = regulator_disable(anx6345->dvdd25);
> + if (err) {
> + DRM_ERROR("Failed to disable dvdd25 regulator: %d\n",
> + err);
> + return;
> + }
> +
> + usleep_range(5000, 10000);
> +
> + err = regulator_disable(anx6345->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 eDP transmitter initialization: %d\n", err);
> + anx6345_poweroff(anx6345);
> + return err;
> + }
> +
> + err = anx6345_dp_link_training(anx6345);
> + if (err) {
> + DRM_ERROR("Failed link training: %d\n", err);
> + anx6345_poweroff(anx6345);
> + return err;
> + }
> +
> + /*
> + * 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;
> +}
> +
> +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;
> + bool power_off = false;
> +
> + mutex_lock(&anx6345->lock);
> +
> + if (!anx6345->edid) {
> + if (!anx6345->powered) {
> + anx6345_poweron(anx6345);
> + power_off = true;
> + }
> +
> + 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:
> + if (power_off)
> + anx6345_poweroff(anx6345);
> +
> + mutex_unlock(&anx6345->lock);
> +
> + if (!num_modes && 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 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,
> + .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 enum drm_mode_status
> +anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> + return MODE_NO_INTERLACE;
> +
> + /* Max 1200p at 5.4 Ghz, one lane */
> + if (mode->clock > 154000)
> + return MODE_CLOCK_HIGH;
I wonder if you shouldn't take into account training results here, ie.
training perfrormed before validation.
> +
> + return MODE_OK;
> +}
> +
> +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);
> +
> + if (anx6345->powered)
> + anx6345_poweroff(anx6345);
> +}
> +
> +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_valid = anx6345_bridge_mode_valid,
> + .disable = anx6345_bridge_disable,
> + .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,
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +static const u16 anx6345_chipid_list[] = {
> + 0x6345,
> +};
> +
> +static bool anx6345_get_chip_id(struct anx6345 *anx6345)
> +{
> + unsigned int i, idl, idh, version;
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDL_REG, &idl))
> + return false;
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_IDH_REG, &idh))
> + return false;
> +
> + anx6345->chipid = (u8)idl | ((u8)idh << 8);
> +
> + if (regmap_read(anx6345->map[I2C_IDX_TXCOM], SP_DEVICE_VERSION_REG,
> + &version))
> + return false;
> +
> + 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);
> + return true;
> + }
> + }
> +
> + DRM_ERROR("ANX%x (ver. %d) not supported by this driver\n",
> + anx6345->chipid, version);
> +
> + return false;
> +}
> +
> +static int anx6345_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct anx6345 *anx6345;
> + struct device *dev;
> + int i, err;
> +
> + anx6345 = devm_kzalloc(&client->dev, sizeof(*anx6345), GFP_KERNEL);
> + if (!anx6345)
> + return -ENOMEM;
> +
> + mutex_init(&anx6345->lock);
> +
> + anx6345->bridge.of_node = client->dev.of_node;
> +
> + anx6345->client = client;
> + i2c_set_clientdata(client, anx6345);
> +
> + dev = &anx6345->client->dev;
> +
> + 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");
> +
> + /* 1.2V digital core power regulator */
> + anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply");
> + if (IS_ERR(anx6345->dvdd12)) {
> + DRM_ERROR("dvdd12-supply not found\n");
> + return PTR_ERR(anx6345->dvdd12);
> + }
> +
> + /* 2.5V digital core power regulator */
> + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
> + if (IS_ERR(anx6345->dvdd25)) {
> + DRM_ERROR("dvdd25-supply not found\n");
> + return PTR_ERR(anx6345->dvdd25);
> + }
> +
> + /* GPIO for chip reset */
> + anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
Shouldn't be set to GPIOD_OUT_HIGH?
> + if (IS_ERR(anx6345->gpiod_reset)) {
> + DRM_ERROR("Reset gpio not found\n");
> + return PTR_ERR(anx6345->gpiod_reset);
> + }
> +
> + /* 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);
> + if (anx6345_get_chip_id(anx6345)) {
> + anx6345->bridge.funcs = &anx6345_bridge_funcs;
> + drm_bridge_add(&anx6345->bridge);
> +
> + return 0;
> + } else {
> + anx6345_poweroff(anx6345);
> + err = -ENODEV;
> + }
> +
> +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);
> +
> + mutex_destroy(&anx6345->lock);
> +
> + 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("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
Submitter, patch author, and module author are different, this can be
correct, but maybe somebody forgot to update some of these fields.
Regards
Andrzej
> +MODULE_LICENSE("GPL v2");
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-07 9:40 ` Torsten Duwe
(?)
@ 2019-06-12 10:00 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 10:00 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard
Cc: Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Greg Kroah-Hartman,
Thomas Gleixner, dri-devel, devicetree, arm-linux, linux-kernel
On 07.06.2019 11:40, Torsten Duwe wrote:
> On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
>> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
>>> If think valid compatible properties would be:
>>> compatible = "innolux,n116bge", "simple-panel";
>>> compatible = "edp-connector", "simple-panel";
>> A connector isn't a panel.
>>
>>> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
>> And the innolux,n116bge is certainly not a connector either.
>>
>>> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
>>>
>>> I can't make up my mind which one I prefere. However neither of these
>>> variants requires actually implmenting an edp-connector driver.
>> No-one asked to do an edp-connector driver. You should use it in your
>> DT, but if you want to have some code in your driver that parses the
>> DT directly, I'm totally fine with that.
> I must admit I fail to understand what that extra node would be good for.
> Logically, the eDP far side is connected to the well-known n116bge.
> Inside the laptop case it might as well be a flat ribbon cable or
> soldered directly.
> In good intention, that's all I wanted to express in the DT. I don't
> know whether the relevant mechanical dimensions of the panel and the
> connector are standardised, so whether one could in theory assemble it
> with a different panel than the one it came with.
>
> OTOH, as I checked during the discussion with anarsoul, the panel's
> supply voltage is permanently connected to the main 3.3V rail.
> We already agreed that the eDP output port must not neccessarily be
> specified, this setup is a good example why: because the panel is
> always powered, the anx6345 can always pull valid EDID data from it
> so at this stage there's no need for any OS driver to reach beyond
> the bridge. IIRC even the backlight got switched off for the blank
> screen without.
>
> All I wanted to say is that "there's usually an n116bge behind it";
> but this is mostly redundant.
>
> So, shall we just drop the output port specification (along with the
> panel node) in order to get one step further?
I am not sure if I understand whole discussion here, but I also do not
understand whole edp-connector thing.
According to VESA[1] eDP is "Internal display interface" - there is no
external connector for eDP, the way it is connected is integrator's
decision, but it is fixed - ie end user do not plug/unplug it.
If I remember correctly in some boards eDP is connected to some DP
connector (odroid xu3 if I remember correctly), but this is non-standard
hack, and for this case in bindings there should be rather dp-connector
not edp-connector.
[1]:
https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf
Regards
Andrzej
>
>> I guess you should describe why do you think it's "clear", because I'm
>> not sure this is obvious for everyone here. eDP allows to discover
>> which device is on the other side and its supported timings, just like
>> HDMI for example (or regular DP, for that matter). Would you think
>> it's clearly preferable to ship a DT with the DP/HDMI monitor
>> connected on the other side exposed as a panel as well?
> Well, as I wrote: "in good intention". That's the panel that comes with
> the kit but it is very well detected automatically, just like you describe.
>
> So, just leave it out?
>
> Torsten
>
>
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-12 10:00 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 10:00 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Thierry Reding, Laurent Pinchart, Harald Geyer,
Sean Paul, Thomas Gleixner, arm-linux, Icenowy Zheng
On 07.06.2019 11:40, Torsten Duwe wrote:
> On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
>> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
>>> If think valid compatible properties would be:
>>> compatible = "innolux,n116bge", "simple-panel";
>>> compatible = "edp-connector", "simple-panel";
>> A connector isn't a panel.
>>
>>> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
>> And the innolux,n116bge is certainly not a connector either.
>>
>>> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
>>>
>>> I can't make up my mind which one I prefere. However neither of these
>>> variants requires actually implmenting an edp-connector driver.
>> No-one asked to do an edp-connector driver. You should use it in your
>> DT, but if you want to have some code in your driver that parses the
>> DT directly, I'm totally fine with that.
> I must admit I fail to understand what that extra node would be good for.
> Logically, the eDP far side is connected to the well-known n116bge.
> Inside the laptop case it might as well be a flat ribbon cable or
> soldered directly.
> In good intention, that's all I wanted to express in the DT. I don't
> know whether the relevant mechanical dimensions of the panel and the
> connector are standardised, so whether one could in theory assemble it
> with a different panel than the one it came with.
>
> OTOH, as I checked during the discussion with anarsoul, the panel's
> supply voltage is permanently connected to the main 3.3V rail.
> We already agreed that the eDP output port must not neccessarily be
> specified, this setup is a good example why: because the panel is
> always powered, the anx6345 can always pull valid EDID data from it
> so at this stage there's no need for any OS driver to reach beyond
> the bridge. IIRC even the backlight got switched off for the blank
> screen without.
>
> All I wanted to say is that "there's usually an n116bge behind it";
> but this is mostly redundant.
>
> So, shall we just drop the output port specification (along with the
> panel node) in order to get one step further?
I am not sure if I understand whole discussion here, but I also do not
understand whole edp-connector thing.
According to VESA[1] eDP is "Internal display interface" - there is no
external connector for eDP, the way it is connected is integrator's
decision, but it is fixed - ie end user do not plug/unplug it.
If I remember correctly in some boards eDP is connected to some DP
connector (odroid xu3 if I remember correctly), but this is non-standard
hack, and for this case in bindings there should be rather dp-connector
not edp-connector.
[1]:
https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf
Regards
Andrzej
>
>> I guess you should describe why do you think it's "clear", because I'm
>> not sure this is obvious for everyone here. eDP allows to discover
>> which device is on the other side and its supported timings, just like
>> HDMI for example (or regular DP, for that matter). Would you think
>> it's clearly preferable to ship a DT with the DP/HDMI monitor
>> connected on the other side exposed as a panel as well?
> Well, as I wrote: "in good intention". That's the panel that comes with
> the kit but it is very well detected automatically, just like you describe.
>
> So, just leave it out?
>
> Torsten
>
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-12 10:00 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 10:00 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Harald Geyer,
Sean Paul, Thomas Gleixner, arm-linux, Icenowy Zheng
On 07.06.2019 11:40, Torsten Duwe wrote:
> On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
>> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
>>> If think valid compatible properties would be:
>>> compatible = "innolux,n116bge", "simple-panel";
>>> compatible = "edp-connector", "simple-panel";
>> A connector isn't a panel.
>>
>>> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
>> And the innolux,n116bge is certainly not a connector either.
>>
>>> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
>>>
>>> I can't make up my mind which one I prefere. However neither of these
>>> variants requires actually implmenting an edp-connector driver.
>> No-one asked to do an edp-connector driver. You should use it in your
>> DT, but if you want to have some code in your driver that parses the
>> DT directly, I'm totally fine with that.
> I must admit I fail to understand what that extra node would be good for.
> Logically, the eDP far side is connected to the well-known n116bge.
> Inside the laptop case it might as well be a flat ribbon cable or
> soldered directly.
> In good intention, that's all I wanted to express in the DT. I don't
> know whether the relevant mechanical dimensions of the panel and the
> connector are standardised, so whether one could in theory assemble it
> with a different panel than the one it came with.
>
> OTOH, as I checked during the discussion with anarsoul, the panel's
> supply voltage is permanently connected to the main 3.3V rail.
> We already agreed that the eDP output port must not neccessarily be
> specified, this setup is a good example why: because the panel is
> always powered, the anx6345 can always pull valid EDID data from it
> so at this stage there's no need for any OS driver to reach beyond
> the bridge. IIRC even the backlight got switched off for the blank
> screen without.
>
> All I wanted to say is that "there's usually an n116bge behind it";
> but this is mostly redundant.
>
> So, shall we just drop the output port specification (along with the
> panel node) in order to get one step further?
I am not sure if I understand whole discussion here, but I also do not
understand whole edp-connector thing.
According to VESA[1] eDP is "Internal display interface" - there is no
external connector for eDP, the way it is connected is integrator's
decision, but it is fixed - ie end user do not plug/unplug it.
If I remember correctly in some boards eDP is connected to some DP
connector (odroid xu3 if I remember correctly), but this is non-standard
hack, and for this case in bindings there should be rather dp-connector
not edp-connector.
[1]:
https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf
Regards
Andrzej
>
>> I guess you should describe why do you think it's "clear", because I'm
>> not sure this is obvious for everyone here. eDP allows to discover
>> which device is on the other side and its supported timings, just like
>> HDMI for example (or regular DP, for that matter). Would you think
>> it's clearly preferable to ship a DT with the DP/HDMI monitor
>> connected on the other side exposed as a panel as well?
> Well, as I wrote: "in good intention". That's the panel that comes with
> the kit but it is very well detected automatically, just like you describe.
>
> So, just leave it out?
>
> 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] 90+ messages in thread
* Re: [PATCH v2 1/7] drm/bridge: move ANA78xx driver to analogix subdirectory
2019-06-04 12:22 ` Torsten Duwe
@ 2019-06-12 10:16 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 10:16 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: dri-devel, devicetree, linux-arm-kernel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> 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>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> ---
> 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 +
> drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
> drivers/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 ee777469293a..862789bf64a0 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -16,16 +16,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 e930ff9b5cd4..704fb0f41dc3 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,14 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +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 fdbf3fd2f087..6fcbfd3ee560 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 1/7] drm/bridge: move ANA78xx driver to analogix subdirectory
@ 2019-06-12 10:16 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-12 10:16 UTC (permalink / raw)
To: Torsten Duwe, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Laurent Pinchart, Icenowy Zheng, Sean Paul, Vasily Khoruzhick,
Harald Geyer, Greg Kroah-Hartman, Thomas Gleixner
Cc: devicetree, linux-arm-kernel, dri-devel, linux-kernel
On 04.06.2019 14:22, Torsten Duwe wrote:
> 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>
> Signed-off-by: Torsten Duwe <duwe@suse.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
--
Regards
Andrzej
> ---
> 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 +
> drivers/gpu/drm/bridge/{ => analogix}/analogix-anx78xx.c | 0
> drivers/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 ee777469293a..862789bf64a0 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -16,16 +16,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 e930ff9b5cd4..704fb0f41dc3 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -1,4 +1,14 @@
> # SPDX-License-Identifier: GPL-2.0-only
> +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 fdbf3fd2f087..6fcbfd3ee560 100644
> --- a/drivers/gpu/drm/bridge/analogix/Makefile
> +++ b/drivers/gpu/drm/bridge/analogix/Makefile
> @@ -1,3 +1,4 @@
> # SPDX-License-Identifier: GPL-2.0-only
> 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
_______________________________________________
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] 90+ messages in thread
* Re: [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
2019-06-12 8:16 ` Andrzej Hajda
@ 2019-06-12 14:59 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-12 14:59 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Laurent Pinchart,
Icenowy Zheng, Sean Paul, Vasily Khoruzhick, Harald Geyer,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
linux-arm-kernel, linux-kernel
On Wed, Jun 12, 2019 at 10:16:37AM +0200, Andrzej Hajda wrote:
> > +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
>
>
> You have not specified it's active state, since in driver's code you
> named it RESETN I guess it should be active low.
Yes. The chip's reset is active low.
>
> > + - dvdd12-supply : Regulator for 1.2V digital core power.
> > + - dvdd25-supply : Regulator for 2.5V digital core power.
> > + - Video port for LVTTL input, using the DT bindings defined in [1].
>
>
> Please assign port number for input (I guess 0).
True.
>
> > +
> > +Optional properties:
> > +
> > + - Video port for eDP output (panel or connector) using the DT bindings
> > + defined in [1].
>
>
> Shouldn't it be also required?
See previous discussion. Surely there should be _something_ connected to
the output side, but that something might not be relevant for the software
side, so it might be omitted from the device tree.
In fact, I'll submit v3 with the SPDX changes and without exactly this
output port spec which had caused the heated discussion.
Torsten
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding
@ 2019-06-12 14:59 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-06-12 14:59 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Mark Rutland, devicetree, Maxime Ripard, Greg Kroah-Hartman,
linux-kernel, dri-devel, David Airlie, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Harald Geyer,
Sean Paul, Thomas Gleixner, linux-arm-kernel, Icenowy Zheng
On Wed, Jun 12, 2019 at 10:16:37AM +0200, Andrzej Hajda wrote:
> > +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
>
>
> You have not specified it's active state, since in driver's code you
> named it RESETN I guess it should be active low.
Yes. The chip's reset is active low.
>
> > + - dvdd12-supply : Regulator for 1.2V digital core power.
> > + - dvdd25-supply : Regulator for 2.5V digital core power.
> > + - Video port for LVTTL input, using the DT bindings defined in [1].
>
>
> Please assign port number for input (I guess 0).
True.
>
> > +
> > +Optional properties:
> > +
> > + - Video port for eDP output (panel or connector) using the DT bindings
> > + defined in [1].
>
>
> Shouldn't it be also required?
See previous discussion. Surely there should be _something_ connected to
the output side, but that something might not be relevant for the software
side, so it might be omitted from the device tree.
In fact, I'll submit v3 with the SPDX changes and without exactly this
output port spec which had caused the heated discussion.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-12 10:00 ` Andrzej Hajda
(?)
@ 2019-06-12 15:20 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-12 15:20 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Torsten Duwe, Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]
Hi,
On Wed, Jun 12, 2019 at 12:00:21PM +0200, Andrzej Hajda wrote:
> On 07.06.2019 11:40, Torsten Duwe wrote:
> > On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> >> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> >>> If think valid compatible properties would be:
> >>> compatible = "innolux,n116bge", "simple-panel";
> >>> compatible = "edp-connector", "simple-panel";
> >> A connector isn't a panel.
> >>
> >>> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
> >> And the innolux,n116bge is certainly not a connector either.
> >>
> >>> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> >>>
> >>> I can't make up my mind which one I prefere. However neither of these
> >>> variants requires actually implmenting an edp-connector driver.
> >> No-one asked to do an edp-connector driver. You should use it in your
> >> DT, but if you want to have some code in your driver that parses the
> >> DT directly, I'm totally fine with that.
> > I must admit I fail to understand what that extra node would be good for.
> > Logically, the eDP far side is connected to the well-known n116bge.
> > Inside the laptop case it might as well be a flat ribbon cable or
> > soldered directly.
> > In good intention, that's all I wanted to express in the DT. I don't
> > know whether the relevant mechanical dimensions of the panel and the
> > connector are standardised, so whether one could in theory assemble it
> > with a different panel than the one it came with.
> >
> > OTOH, as I checked during the discussion with anarsoul, the panel's
> > supply voltage is permanently connected to the main 3.3V rail.
> > We already agreed that the eDP output port must not neccessarily be
> > specified, this setup is a good example why: because the panel is
> > always powered, the anx6345 can always pull valid EDID data from it
> > so at this stage there's no need for any OS driver to reach beyond
> > the bridge. IIRC even the backlight got switched off for the blank
> > screen without.
> >
> > All I wanted to say is that "there's usually an n116bge behind it";
> > but this is mostly redundant.
> >
> > So, shall we just drop the output port specification (along with the
> > panel node) in order to get one step further?
>
> I am not sure if I understand whole discussion here, but I also do not
> understand whole edp-connector thing.
The context is this one:
https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
TL;DR: This bridge is being used on ARM laptops that can come with
different eDP panels. Some of these panels require a regulator to be
enabled for the panel to work, and this is obviously something that
should be in the DT.
However, we can't really describe the panel itself, since the vendor
uses several of them and just relies on the eDP bus to do its job at
retrieving the EDIDs. A generic panel isn't really working either
since that would mean having a generic behaviour for all the panels
connected to that bus, which isn't there either.
The connector allows to expose this nicely.
> According to VESA[1] eDP is "Internal display interface" - there is no
> external connector for eDP, the way it is connected is integrator's
> decision, but it is fixed - ie end user do not plug/unplug it.
I'm not sure if you mean DRM or DT connector here though. In DRM,
we're doing this all the time for panels. I'm literaly typing this
from a laptop that has a screen with an eDP connector.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-12 15:20 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-12 15:20 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Vasily Khoruzhick,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Harald Geyer, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 3781 bytes --]
Hi,
On Wed, Jun 12, 2019 at 12:00:21PM +0200, Andrzej Hajda wrote:
> On 07.06.2019 11:40, Torsten Duwe wrote:
> > On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> >> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> >>> If think valid compatible properties would be:
> >>> compatible = "innolux,n116bge", "simple-panel";
> >>> compatible = "edp-connector", "simple-panel";
> >> A connector isn't a panel.
> >>
> >>> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
> >> And the innolux,n116bge is certainly not a connector either.
> >>
> >>> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> >>>
> >>> I can't make up my mind which one I prefere. However neither of these
> >>> variants requires actually implmenting an edp-connector driver.
> >> No-one asked to do an edp-connector driver. You should use it in your
> >> DT, but if you want to have some code in your driver that parses the
> >> DT directly, I'm totally fine with that.
> > I must admit I fail to understand what that extra node would be good for.
> > Logically, the eDP far side is connected to the well-known n116bge.
> > Inside the laptop case it might as well be a flat ribbon cable or
> > soldered directly.
> > In good intention, that's all I wanted to express in the DT. I don't
> > know whether the relevant mechanical dimensions of the panel and the
> > connector are standardised, so whether one could in theory assemble it
> > with a different panel than the one it came with.
> >
> > OTOH, as I checked during the discussion with anarsoul, the panel's
> > supply voltage is permanently connected to the main 3.3V rail.
> > We already agreed that the eDP output port must not neccessarily be
> > specified, this setup is a good example why: because the panel is
> > always powered, the anx6345 can always pull valid EDID data from it
> > so at this stage there's no need for any OS driver to reach beyond
> > the bridge. IIRC even the backlight got switched off for the blank
> > screen without.
> >
> > All I wanted to say is that "there's usually an n116bge behind it";
> > but this is mostly redundant.
> >
> > So, shall we just drop the output port specification (along with the
> > panel node) in order to get one step further?
>
> I am not sure if I understand whole discussion here, but I also do not
> understand whole edp-connector thing.
The context is this one:
https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
TL;DR: This bridge is being used on ARM laptops that can come with
different eDP panels. Some of these panels require a regulator to be
enabled for the panel to work, and this is obviously something that
should be in the DT.
However, we can't really describe the panel itself, since the vendor
uses several of them and just relies on the eDP bus to do its job at
retrieving the EDIDs. A generic panel isn't really working either
since that would mean having a generic behaviour for all the panels
connected to that bus, which isn't there either.
The connector allows to expose this nicely.
> According to VESA[1] eDP is "Internal display interface" - there is no
> external connector for eDP, the way it is connected is integrator's
> decision, but it is fixed - ie end user do not plug/unplug it.
I'm not sure if you mean DRM or DT connector here though. In DRM,
we're doing this all the time for panels. I'm literaly typing this
from a laptop that has a screen with an eDP connector.
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: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-12 15:20 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-12 15:20 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 3781 bytes --]
Hi,
On Wed, Jun 12, 2019 at 12:00:21PM +0200, Andrzej Hajda wrote:
> On 07.06.2019 11:40, Torsten Duwe wrote:
> > On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> >> On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> >>> If think valid compatible properties would be:
> >>> compatible = "innolux,n116bge", "simple-panel";
> >>> compatible = "edp-connector", "simple-panel";
> >> A connector isn't a panel.
> >>
> >>> compatible = "innolux,n116bge", "edp-connector", "simple-panel";
> >> And the innolux,n116bge is certainly not a connector either.
> >>
> >>> compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> >>>
> >>> I can't make up my mind which one I prefere. However neither of these
> >>> variants requires actually implmenting an edp-connector driver.
> >> No-one asked to do an edp-connector driver. You should use it in your
> >> DT, but if you want to have some code in your driver that parses the
> >> DT directly, I'm totally fine with that.
> > I must admit I fail to understand what that extra node would be good for.
> > Logically, the eDP far side is connected to the well-known n116bge.
> > Inside the laptop case it might as well be a flat ribbon cable or
> > soldered directly.
> > In good intention, that's all I wanted to express in the DT. I don't
> > know whether the relevant mechanical dimensions of the panel and the
> > connector are standardised, so whether one could in theory assemble it
> > with a different panel than the one it came with.
> >
> > OTOH, as I checked during the discussion with anarsoul, the panel's
> > supply voltage is permanently connected to the main 3.3V rail.
> > We already agreed that the eDP output port must not neccessarily be
> > specified, this setup is a good example why: because the panel is
> > always powered, the anx6345 can always pull valid EDID data from it
> > so at this stage there's no need for any OS driver to reach beyond
> > the bridge. IIRC even the backlight got switched off for the blank
> > screen without.
> >
> > All I wanted to say is that "there's usually an n116bge behind it";
> > but this is mostly redundant.
> >
> > So, shall we just drop the output port specification (along with the
> > panel node) in order to get one step further?
>
> I am not sure if I understand whole discussion here, but I also do not
> understand whole edp-connector thing.
The context is this one:
https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
TL;DR: This bridge is being used on ARM laptops that can come with
different eDP panels. Some of these panels require a regulator to be
enabled for the panel to work, and this is obviously something that
should be in the DT.
However, we can't really describe the panel itself, since the vendor
uses several of them and just relies on the eDP bus to do its job at
retrieving the EDIDs. A generic panel isn't really working either
since that would mean having a generic behaviour for all the panels
connected to that bus, which isn't there either.
The connector allows to expose this nicely.
> According to VESA[1] eDP is "Internal display interface" - there is no
> external connector for eDP, the way it is connected is integrator's
> decision, but it is fixed - ie end user do not plug/unplug it.
I'm not sure if you mean DRM or DT connector here though. In DRM,
we're doing this all the time for panels. I'm literaly typing this
from a laptop that has a screen with an eDP connector.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-07 9:40 ` Torsten Duwe
(?)
@ 2019-06-12 15:34 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-12 15:34 UTC (permalink / raw)
To: Torsten Duwe
Cc: Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai, Rob Herring,
Mark Rutland, Thierry Reding, David Airlie, Daniel Vetter,
Andrzej Hajda, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]
On Fri, Jun 07, 2019 at 11:40:30AM +0200, Torsten Duwe wrote:
> On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> > On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> > >
> > > If think valid compatible properties would be:
> > > compatible = "innolux,n116bge", "simple-panel";
> > > compatible = "edp-connector", "simple-panel";
> >
> > A connector isn't a panel.
> >
> > > compatible = "innolux,n116bge", "edp-connector", "simple-panel";
> >
> > And the innolux,n116bge is certainly not a connector either.
> >
> > > compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> > >
> > > I can't make up my mind which one I prefere. However neither of these
> > > variants requires actually implmenting an edp-connector driver.
> >
> > No-one asked to do an edp-connector driver. You should use it in your
> > DT, but if you want to have some code in your driver that parses the
> > DT directly, I'm totally fine with that.
>
> I must admit I fail to understand what that extra node would be good for.
> Logically, the eDP far side is connected to the well-known n116bge.
> Inside the laptop case it might as well be a flat ribbon cable or
> soldered directly.
> In good intention, that's all I wanted to express in the DT. I don't
> know whether the relevant mechanical dimensions of the panel and the
> connector are standardised, so whether one could in theory assemble it
> with a different panel than the one it came with.
Because the panel that comes with the Teres-I is always the
same. However, that's not true for all the devices out there using the
bridge, starting with the pinebook.
> OTOH, as I checked during the discussion with anarsoul, the panel's
> supply voltage is permanently connected to the main 3.3V rail.
Again, that may be the case on the Teres-I, but not necessarily on
other boards.
> We already agreed that the eDP output port must not neccessarily be
> specified, this setup is a good example why: because the panel is
> always powered, the anx6345 can always pull valid EDID data from it
> so at this stage there's no need for any OS driver to reach beyond
> the bridge. IIRC even the backlight got switched off for the blank
> screen without.
That's not really the outcome of the discussion we had here though:
https://patchwork.freedesktop.org/patch/305035/
> All I wanted to say is that "there's usually an n116bge behind it";
> but this is mostly redundant.
>
> So, shall we just drop the output port specification (along with the
> panel node) in order to get one step further?
Depending on the outcome of the discussion above, yes or no :)
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-12 15:34 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-12 15:34 UTC (permalink / raw)
To: Torsten Duwe
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Thierry Reding, Laurent Pinchart, Harald Geyer,
Sean Paul, Thomas Gleixner, arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 2713 bytes --]
On Fri, Jun 07, 2019 at 11:40:30AM +0200, Torsten Duwe wrote:
> On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> > On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> > >
> > > If think valid compatible properties would be:
> > > compatible = "innolux,n116bge", "simple-panel";
> > > compatible = "edp-connector", "simple-panel";
> >
> > A connector isn't a panel.
> >
> > > compatible = "innolux,n116bge", "edp-connector", "simple-panel";
> >
> > And the innolux,n116bge is certainly not a connector either.
> >
> > > compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> > >
> > > I can't make up my mind which one I prefere. However neither of these
> > > variants requires actually implmenting an edp-connector driver.
> >
> > No-one asked to do an edp-connector driver. You should use it in your
> > DT, but if you want to have some code in your driver that parses the
> > DT directly, I'm totally fine with that.
>
> I must admit I fail to understand what that extra node would be good for.
> Logically, the eDP far side is connected to the well-known n116bge.
> Inside the laptop case it might as well be a flat ribbon cable or
> soldered directly.
> In good intention, that's all I wanted to express in the DT. I don't
> know whether the relevant mechanical dimensions of the panel and the
> connector are standardised, so whether one could in theory assemble it
> with a different panel than the one it came with.
Because the panel that comes with the Teres-I is always the
same. However, that's not true for all the devices out there using the
bridge, starting with the pinebook.
> OTOH, as I checked during the discussion with anarsoul, the panel's
> supply voltage is permanently connected to the main 3.3V rail.
Again, that may be the case on the Teres-I, but not necessarily on
other boards.
> We already agreed that the eDP output port must not neccessarily be
> specified, this setup is a good example why: because the panel is
> always powered, the anx6345 can always pull valid EDID data from it
> so at this stage there's no need for any OS driver to reach beyond
> the bridge. IIRC even the backlight got switched off for the blank
> screen without.
That's not really the outcome of the discussion we had here though:
https://patchwork.freedesktop.org/patch/305035/
> All I wanted to say is that "there's usually an n116bge behind it";
> but this is mostly redundant.
>
> So, shall we just drop the output port specification (along with the
> panel node) in order to get one step further?
Depending on the outcome of the discussion above, yes or no :)
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: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-12 15:34 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-06-12 15:34 UTC (permalink / raw)
To: Torsten Duwe
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Andrzej Hajda, Chen-Yu Tsai,
Rob Herring, Thierry Reding, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Sean Paul, Thomas Gleixner, arm-linux,
Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 2713 bytes --]
On Fri, Jun 07, 2019 at 11:40:30AM +0200, Torsten Duwe wrote:
> On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote:
> > On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote:
> > >
> > > If think valid compatible properties would be:
> > > compatible = "innolux,n116bge", "simple-panel";
> > > compatible = "edp-connector", "simple-panel";
> >
> > A connector isn't a panel.
> >
> > > compatible = "innolux,n116bge", "edp-connector", "simple-panel";
> >
> > And the innolux,n116bge is certainly not a connector either.
> >
> > > compatible = "edp-connector", "innolux,n116bge", "simple-panel";
> > >
> > > I can't make up my mind which one I prefere. However neither of these
> > > variants requires actually implmenting an edp-connector driver.
> >
> > No-one asked to do an edp-connector driver. You should use it in your
> > DT, but if you want to have some code in your driver that parses the
> > DT directly, I'm totally fine with that.
>
> I must admit I fail to understand what that extra node would be good for.
> Logically, the eDP far side is connected to the well-known n116bge.
> Inside the laptop case it might as well be a flat ribbon cable or
> soldered directly.
> In good intention, that's all I wanted to express in the DT. I don't
> know whether the relevant mechanical dimensions of the panel and the
> connector are standardised, so whether one could in theory assemble it
> with a different panel than the one it came with.
Because the panel that comes with the Teres-I is always the
same. However, that's not true for all the devices out there using the
bridge, starting with the pinebook.
> OTOH, as I checked during the discussion with anarsoul, the panel's
> supply voltage is permanently connected to the main 3.3V rail.
Again, that may be the case on the Teres-I, but not necessarily on
other boards.
> We already agreed that the eDP output port must not neccessarily be
> specified, this setup is a good example why: because the panel is
> always powered, the anx6345 can always pull valid EDID data from it
> so at this stage there's no need for any OS driver to reach beyond
> the bridge. IIRC even the backlight got switched off for the blank
> screen without.
That's not really the outcome of the discussion we had here though:
https://patchwork.freedesktop.org/patch/305035/
> All I wanted to say is that "there's usually an n116bge behind it";
> but this is mostly redundant.
>
> So, shall we just drop the output port specification (along with the
> panel node) in order to get one step further?
Depending on the outcome of the discussion above, yes or no :)
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-12 15:20 ` Maxime Ripard
@ 2019-06-28 10:39 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-28 10:39 UTC (permalink / raw)
To: Maxime Ripard
Cc: Torsten Duwe, Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
Hi Maxime,
It seems I have missed your response.
On 12.06.2019 17:20, Maxime Ripard wrote:
>> I am not sure if I understand whole discussion here, but I also do not
>> understand whole edp-connector thing.
> The context is this one:
> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
>
> TL;DR: This bridge is being used on ARM laptops that can come with
> different eDP panels. Some of these panels require a regulator to be
> enabled for the panel to work, and this is obviously something that
> should be in the DT.
>
> However, we can't really describe the panel itself, since the vendor
> uses several of them and just relies on the eDP bus to do its job at
> retrieving the EDIDs. A generic panel isn't really working either
> since that would mean having a generic behaviour for all the panels
> connected to that bus, which isn't there either.
>
> The connector allows to expose this nicely.
As VESA presentation says[1] eDP is based on DP but is much more
flexible, it is up to integrator (!!!) how the connection, power
up/down, initialization sequence should be performed. Trying to cover
every such case in edp-connector seems to me similar to panel-simple
attempt failure. Moreover there is no such thing as physical standard
eDP connector. Till now I though DT connector should describe physical
connector on the device, now I am lost, are there some DT bindings
guidelines about definition of a connector?
Maybe instead of edp-connector one would introduce integrator's specific
connector, for example with compatible "olimex,teres-edp-connector"
which should follow edp abstract connector rules? This will be at least
consistent with below presentation[1] - eDP requirements depends on
integrator. Then if olimex has standard way of dealing with panels
present in olimex/teres platforms the driver would then create
drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
Anyway it still looks fishy for me :), maybe because I am not
familiarized with details of these platforms.
[1]: https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf
>
>> According to VESA[1] eDP is "Internal display interface" - there is no
>> external connector for eDP, the way it is connected is integrator's
>> decision, but it is fixed - ie end user do not plug/unplug it.
> I'm not sure if you mean DRM or DT connector here though. In DRM,
> we're doing this all the time for panels. I'm literaly typing this
> from a laptop that has a screen with an eDP connector.
VESA describes only hardware, but since DT also describes hardware I
guess it should be similar.
Regards
Andrzej
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-06-28 10:39 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-06-28 10:39 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
Hi Maxime,
It seems I have missed your response.
On 12.06.2019 17:20, Maxime Ripard wrote:
>> I am not sure if I understand whole discussion here, but I also do not
>> understand whole edp-connector thing.
> The context is this one:
> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
>
> TL;DR: This bridge is being used on ARM laptops that can come with
> different eDP panels. Some of these panels require a regulator to be
> enabled for the panel to work, and this is obviously something that
> should be in the DT.
>
> However, we can't really describe the panel itself, since the vendor
> uses several of them and just relies on the eDP bus to do its job at
> retrieving the EDIDs. A generic panel isn't really working either
> since that would mean having a generic behaviour for all the panels
> connected to that bus, which isn't there either.
>
> The connector allows to expose this nicely.
As VESA presentation says[1] eDP is based on DP but is much more
flexible, it is up to integrator (!!!) how the connection, power
up/down, initialization sequence should be performed. Trying to cover
every such case in edp-connector seems to me similar to panel-simple
attempt failure. Moreover there is no such thing as physical standard
eDP connector. Till now I though DT connector should describe physical
connector on the device, now I am lost, are there some DT bindings
guidelines about definition of a connector?
Maybe instead of edp-connector one would introduce integrator's specific
connector, for example with compatible "olimex,teres-edp-connector"
which should follow edp abstract connector rules? This will be at least
consistent with below presentation[1] - eDP requirements depends on
integrator. Then if olimex has standard way of dealing with panels
present in olimex/teres platforms the driver would then create
drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
Anyway it still looks fishy for me :), maybe because I am not
familiarized with details of these platforms.
[1]: https://www.vesa.org/wp-content/uploads/2010/12/DisplayPort-DevCon-Presentation-eDP-Dec-2010-v3.pdf
>
>> According to VESA[1] eDP is "Internal display interface" - there is no
>> external connector for eDP, the way it is connected is integrator's
>> decision, but it is fixed - ie end user do not plug/unplug it.
> I'm not sure if you mean DRM or DT connector here though. In DRM,
> we're doing this all the time for panels. I'm literaly typing this
> from a laptop that has a screen with an eDP connector.
VESA describes only hardware, but since DT also describes hardware I
guess it should be similar.
Regards
Andrzej
>
> 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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-06-28 10:39 ` Andrzej Hajda
@ 2019-07-01 9:58 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-01 9:58 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Torsten Duwe, Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2773 bytes --]
Hi!
On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> On 12.06.2019 17:20, Maxime Ripard wrote:
> >> I am not sure if I understand whole discussion here, but I also do not
> >> understand whole edp-connector thing.
> > The context is this one:
> > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> >
> > TL;DR: This bridge is being used on ARM laptops that can come with
> > different eDP panels. Some of these panels require a regulator to be
> > enabled for the panel to work, and this is obviously something that
> > should be in the DT.
> >
> > However, we can't really describe the panel itself, since the vendor
> > uses several of them and just relies on the eDP bus to do its job at
> > retrieving the EDIDs. A generic panel isn't really working either
> > since that would mean having a generic behaviour for all the panels
> > connected to that bus, which isn't there either.
> >
> > The connector allows to expose this nicely.
>
> As VESA presentation says[1] eDP is based on DP but is much more
> flexible, it is up to integrator (!!!) how the connection, power
> up/down, initialization sequence should be performed. Trying to cover
> every such case in edp-connector seems to me similar to panel-simple
> attempt failure. Moreover there is no such thing as physical standard
> eDP connector. Till now I though DT connector should describe physical
> connector on the device, now I am lost, are there some DT bindings
> guidelines about definition of a connector?
This might be semantics but I guess we're in some kind of grey area?
Like, for eDP, if it's soldered I guess we could say that there's no
connector. But what happens if for some other board, that signal is
routed through a ribbon?
You could argue that there's no physical connector in both cases, or
that there's one in both, or one for the ribbon and no connector for
the one soldered in.
> Maybe instead of edp-connector one would introduce integrator's specific
> connector, for example with compatible "olimex,teres-edp-connector"
> which should follow edp abstract connector rules? This will be at least
> consistent with below presentation[1] - eDP requirements depends on
> integrator. Then if olimex has standard way of dealing with panels
> present in olimex/teres platforms the driver would then create
> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> Anyway it still looks fishy for me :), maybe because I am not
> familiarized with details of these platforms.
That makes sense yes
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-01 9:58 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-01 9:58 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 2773 bytes --]
Hi!
On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> On 12.06.2019 17:20, Maxime Ripard wrote:
> >> I am not sure if I understand whole discussion here, but I also do not
> >> understand whole edp-connector thing.
> > The context is this one:
> > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> >
> > TL;DR: This bridge is being used on ARM laptops that can come with
> > different eDP panels. Some of these panels require a regulator to be
> > enabled for the panel to work, and this is obviously something that
> > should be in the DT.
> >
> > However, we can't really describe the panel itself, since the vendor
> > uses several of them and just relies on the eDP bus to do its job at
> > retrieving the EDIDs. A generic panel isn't really working either
> > since that would mean having a generic behaviour for all the panels
> > connected to that bus, which isn't there either.
> >
> > The connector allows to expose this nicely.
>
> As VESA presentation says[1] eDP is based on DP but is much more
> flexible, it is up to integrator (!!!) how the connection, power
> up/down, initialization sequence should be performed. Trying to cover
> every such case in edp-connector seems to me similar to panel-simple
> attempt failure. Moreover there is no such thing as physical standard
> eDP connector. Till now I though DT connector should describe physical
> connector on the device, now I am lost, are there some DT bindings
> guidelines about definition of a connector?
This might be semantics but I guess we're in some kind of grey area?
Like, for eDP, if it's soldered I guess we could say that there's no
connector. But what happens if for some other board, that signal is
routed through a ribbon?
You could argue that there's no physical connector in both cases, or
that there's one in both, or one for the ribbon and no connector for
the one soldered in.
> Maybe instead of edp-connector one would introduce integrator's specific
> connector, for example with compatible "olimex,teres-edp-connector"
> which should follow edp abstract connector rules? This will be at least
> consistent with below presentation[1] - eDP requirements depends on
> integrator. Then if olimex has standard way of dealing with panels
> present in olimex/teres platforms the driver would then create
> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> Anyway it still looks fishy for me :), maybe because I am not
> familiarized with details of these platforms.
That makes sense yes
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-01 9:58 ` Maxime Ripard
@ 2019-07-01 12:27 ` Andrzej Hajda
-1 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-07-01 12:27 UTC (permalink / raw)
To: Maxime Ripard
Cc: Torsten Duwe, Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On 01.07.2019 11:58, Maxime Ripard wrote:
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
>> On 12.06.2019 17:20, Maxime Ripard wrote:
>>>> I am not sure if I understand whole discussion here, but I also do not
>>>> understand whole edp-connector thing.
>>> The context is this one:
>>> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
>>> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
>>> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
>>>
>>> TL;DR: This bridge is being used on ARM laptops that can come with
>>> different eDP panels. Some of these panels require a regulator to be
>>> enabled for the panel to work, and this is obviously something that
>>> should be in the DT.
>>>
>>> However, we can't really describe the panel itself, since the vendor
>>> uses several of them and just relies on the eDP bus to do its job at
>>> retrieving the EDIDs. A generic panel isn't really working either
>>> since that would mean having a generic behaviour for all the panels
>>> connected to that bus, which isn't there either.
>>>
>>> The connector allows to expose this nicely.
>> As VESA presentation says[1] eDP is based on DP but is much more
>> flexible, it is up to integrator (!!!) how the connection, power
>> up/down, initialization sequence should be performed. Trying to cover
>> every such case in edp-connector seems to me similar to panel-simple
>> attempt failure. Moreover there is no such thing as physical standard
>> eDP connector. Till now I though DT connector should describe physical
>> connector on the device, now I am lost, are there some DT bindings
>> guidelines about definition of a connector?
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.
This is not about ribbon vs soldering. It is about usage: this
connection is static across the whole life of the device (except
exceptional things: repair, non-standard usage, etc).
And "the real connector" is (at least for me) something where end-user
can connect/disconnect different things: USB, HDMI, ethernet, etc. And
obviously to be functional it should be somehow standardized. So even if
there could be some grey area, I do not see it here.
>
>> Maybe instead of edp-connector one would introduce integrator's specific
>> connector, for example with compatible "olimex,teres-edp-connector"
>> which should follow edp abstract connector rules? This will be at least
>> consistent with below presentation[1] - eDP requirements depends on
>> integrator. Then if olimex has standard way of dealing with panels
>> present in olimex/teres platforms the driver would then create
>> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
>> Anyway it still looks fishy for me :), maybe because I am not
>> familiarized with details of these platforms.
> That makes sense yes
And what if some panel can be used with this pseudo-connecter and in
some different hw directly? Code duplication? DT overlays?
Regards
Andrzej
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-01 12:27 ` Andrzej Hajda
0 siblings, 0 replies; 90+ messages in thread
From: Andrzej Hajda @ 2019-07-01 12:27 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
On 01.07.2019 11:58, Maxime Ripard wrote:
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
>> On 12.06.2019 17:20, Maxime Ripard wrote:
>>>> I am not sure if I understand whole discussion here, but I also do not
>>>> understand whole edp-connector thing.
>>> The context is this one:
>>> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
>>> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
>>> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
>>>
>>> TL;DR: This bridge is being used on ARM laptops that can come with
>>> different eDP panels. Some of these panels require a regulator to be
>>> enabled for the panel to work, and this is obviously something that
>>> should be in the DT.
>>>
>>> However, we can't really describe the panel itself, since the vendor
>>> uses several of them and just relies on the eDP bus to do its job at
>>> retrieving the EDIDs. A generic panel isn't really working either
>>> since that would mean having a generic behaviour for all the panels
>>> connected to that bus, which isn't there either.
>>>
>>> The connector allows to expose this nicely.
>> As VESA presentation says[1] eDP is based on DP but is much more
>> flexible, it is up to integrator (!!!) how the connection, power
>> up/down, initialization sequence should be performed. Trying to cover
>> every such case in edp-connector seems to me similar to panel-simple
>> attempt failure. Moreover there is no such thing as physical standard
>> eDP connector. Till now I though DT connector should describe physical
>> connector on the device, now I am lost, are there some DT bindings
>> guidelines about definition of a connector?
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.
This is not about ribbon vs soldering. It is about usage: this
connection is static across the whole life of the device (except
exceptional things: repair, non-standard usage, etc).
And "the real connector" is (at least for me) something where end-user
can connect/disconnect different things: USB, HDMI, ethernet, etc. And
obviously to be functional it should be somehow standardized. So even if
there could be some grey area, I do not see it here.
>
>> Maybe instead of edp-connector one would introduce integrator's specific
>> connector, for example with compatible "olimex,teres-edp-connector"
>> which should follow edp abstract connector rules? This will be at least
>> consistent with below presentation[1] - eDP requirements depends on
>> integrator. Then if olimex has standard way of dealing with panels
>> present in olimex/teres platforms the driver would then create
>> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
>> Anyway it still looks fishy for me :), maybe because I am not
>> familiarized with details of these platforms.
> That makes sense yes
And what if some panel can be used with this pseudo-connecter and in
some different hw directly? Code duplication? DT overlays?
Regards
Andrzej
>
> 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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-01 12:27 ` Andrzej Hajda
@ 2019-07-02 8:13 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-02 8:13 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Torsten Duwe, Harald Geyer, Vasily Khoruzhick, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4074 bytes --]
On Mon, Jul 01, 2019 at 02:27:51PM +0200, Andrzej Hajda wrote:
> On 01.07.2019 11:58, Maxime Ripard wrote:
> > On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> >> On 12.06.2019 17:20, Maxime Ripard wrote:
> >>>> I am not sure if I understand whole discussion here, but I also do not
> >>>> understand whole edp-connector thing.
> >>> The context is this one:
> >>> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> >>> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> >>> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> >>>
> >>> TL;DR: This bridge is being used on ARM laptops that can come with
> >>> different eDP panels. Some of these panels require a regulator to be
> >>> enabled for the panel to work, and this is obviously something that
> >>> should be in the DT.
> >>>
> >>> However, we can't really describe the panel itself, since the vendor
> >>> uses several of them and just relies on the eDP bus to do its job at
> >>> retrieving the EDIDs. A generic panel isn't really working either
> >>> since that would mean having a generic behaviour for all the panels
> >>> connected to that bus, which isn't there either.
> >>>
> >>> The connector allows to expose this nicely.
> >> As VESA presentation says[1] eDP is based on DP but is much more
> >> flexible, it is up to integrator (!!!) how the connection, power
> >> up/down, initialization sequence should be performed. Trying to cover
> >> every such case in edp-connector seems to me similar to panel-simple
> >> attempt failure. Moreover there is no such thing as physical standard
> >> eDP connector. Till now I though DT connector should describe physical
> >> connector on the device, now I am lost, are there some DT bindings
> >> guidelines about definition of a connector?
> > This might be semantics but I guess we're in some kind of grey area?
> >
> > Like, for eDP, if it's soldered I guess we could say that there's no
> > connector. But what happens if for some other board, that signal is
> > routed through a ribbon?
> >
> > You could argue that there's no physical connector in both cases, or
> > that there's one in both, or one for the ribbon and no connector for
> > the one soldered in.
>
> This is not about ribbon vs soldering. It is about usage: this
> connection is static across the whole life of the device (except
> exceptional things: repair, non-standard usage, etc).
It doesn't have to be.
> And "the real connector" is (at least for me) something where
> end-user can connect/disconnect different things: USB, HDMI,
> ethernet, etc. And obviously to be functional it should be somehow
> standardized. So even if there could be some grey area, I do not see
> it here.
Well, if there's a ribbon connector, then you have a physical
connector, with the end user being able to connect / disconnect
various displays. It might not be the case with actual products, but
it's pretty common with SBCs to have that signal routed through a
connector, and the user has several options to connect a display to
it.
The line really is blurred.
> >> Maybe instead of edp-connector one would introduce integrator's specific
> >> connector, for example with compatible "olimex,teres-edp-connector"
> >> which should follow edp abstract connector rules? This will be at least
> >> consistent with below presentation[1] - eDP requirements depends on
> >> integrator. Then if olimex has standard way of dealing with panels
> >> present in olimex/teres platforms the driver would then create
> >> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> >> Anyway it still looks fishy for me :), maybe because I am not
> >> familiarized with details of these platforms.
>
> > That makes sense yes
>
> And what if some panel can be used with this pseudo-connecter and in
> some different hw directly? Code duplication? DT overlays?
Overlays are a solution, but I would advocate to always have the
connector.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-02 8:13 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-02 8:13 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Thierry Reding, Thomas Gleixner, arm-linux,
Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 4074 bytes --]
On Mon, Jul 01, 2019 at 02:27:51PM +0200, Andrzej Hajda wrote:
> On 01.07.2019 11:58, Maxime Ripard wrote:
> > On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> >> On 12.06.2019 17:20, Maxime Ripard wrote:
> >>>> I am not sure if I understand whole discussion here, but I also do not
> >>>> understand whole edp-connector thing.
> >>> The context is this one:
> >>> https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> >>> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> >>> https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> >>>
> >>> TL;DR: This bridge is being used on ARM laptops that can come with
> >>> different eDP panels. Some of these panels require a regulator to be
> >>> enabled for the panel to work, and this is obviously something that
> >>> should be in the DT.
> >>>
> >>> However, we can't really describe the panel itself, since the vendor
> >>> uses several of them and just relies on the eDP bus to do its job at
> >>> retrieving the EDIDs. A generic panel isn't really working either
> >>> since that would mean having a generic behaviour for all the panels
> >>> connected to that bus, which isn't there either.
> >>>
> >>> The connector allows to expose this nicely.
> >> As VESA presentation says[1] eDP is based on DP but is much more
> >> flexible, it is up to integrator (!!!) how the connection, power
> >> up/down, initialization sequence should be performed. Trying to cover
> >> every such case in edp-connector seems to me similar to panel-simple
> >> attempt failure. Moreover there is no such thing as physical standard
> >> eDP connector. Till now I though DT connector should describe physical
> >> connector on the device, now I am lost, are there some DT bindings
> >> guidelines about definition of a connector?
> > This might be semantics but I guess we're in some kind of grey area?
> >
> > Like, for eDP, if it's soldered I guess we could say that there's no
> > connector. But what happens if for some other board, that signal is
> > routed through a ribbon?
> >
> > You could argue that there's no physical connector in both cases, or
> > that there's one in both, or one for the ribbon and no connector for
> > the one soldered in.
>
> This is not about ribbon vs soldering. It is about usage: this
> connection is static across the whole life of the device (except
> exceptional things: repair, non-standard usage, etc).
It doesn't have to be.
> And "the real connector" is (at least for me) something where
> end-user can connect/disconnect different things: USB, HDMI,
> ethernet, etc. And obviously to be functional it should be somehow
> standardized. So even if there could be some grey area, I do not see
> it here.
Well, if there's a ribbon connector, then you have a physical
connector, with the end user being able to connect / disconnect
various displays. It might not be the case with actual products, but
it's pretty common with SBCs to have that signal routed through a
connector, and the user has several options to connect a display to
it.
The line really is blurred.
> >> Maybe instead of edp-connector one would introduce integrator's specific
> >> connector, for example with compatible "olimex,teres-edp-connector"
> >> which should follow edp abstract connector rules? This will be at least
> >> consistent with below presentation[1] - eDP requirements depends on
> >> integrator. Then if olimex has standard way of dealing with panels
> >> present in olimex/teres platforms the driver would then create
> >> drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> >> Anyway it still looks fishy for me :), maybe because I am not
> >> familiarized with details of these platforms.
>
> > That makes sense yes
>
> And what if some panel can be used with this pseudo-connecter and in
> some different hw directly? Code duplication? DT overlays?
Overlays are a solution, but I would advocate to always have the
connector.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-01 9:58 ` Maxime Ripard
(?)
@ 2019-07-09 0:49 ` Vasily Khoruzhick
-1 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-09 0:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Mon, Jul 1, 2019 at 2:58 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> > On 12.06.2019 17:20, Maxime Ripard wrote:
> > >> I am not sure if I understand whole discussion here, but I also do not
> > >> understand whole edp-connector thing.
> > > The context is this one:
> > > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> > > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> > >
> > > TL;DR: This bridge is being used on ARM laptops that can come with
> > > different eDP panels. Some of these panels require a regulator to be
> > > enabled for the panel to work, and this is obviously something that
> > > should be in the DT.
> > >
> > > However, we can't really describe the panel itself, since the vendor
> > > uses several of them and just relies on the eDP bus to do its job at
> > > retrieving the EDIDs. A generic panel isn't really working either
> > > since that would mean having a generic behaviour for all the panels
> > > connected to that bus, which isn't there either.
> > >
> > > The connector allows to expose this nicely.
> >
> > As VESA presentation says[1] eDP is based on DP but is much more
> > flexible, it is up to integrator (!!!) how the connection, power
> > up/down, initialization sequence should be performed. Trying to cover
> > every such case in edp-connector seems to me similar to panel-simple
> > attempt failure. Moreover there is no such thing as physical standard
> > eDP connector. Till now I though DT connector should describe physical
> > connector on the device, now I am lost, are there some DT bindings
> > guidelines about definition of a connector?
>
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.
>
> > Maybe instead of edp-connector one would introduce integrator's specific
> > connector, for example with compatible "olimex,teres-edp-connector"
> > which should follow edp abstract connector rules? This will be at least
> > consistent with below presentation[1] - eDP requirements depends on
> > integrator. Then if olimex has standard way of dealing with panels
> > present in olimex/teres platforms the driver would then create
> > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > Anyway it still looks fishy for me :), maybe because I am not
> > familiarized with details of these platforms.
>
> That makes sense yes
Actually, it makes no sense at all. Current implementation for anx6345
driver works fine as is with any panel specified assuming panel delays
are long enough for connected panel. It just doesn't use panel timings
from the driver. Creating a platform driver for connector itself looks
redundant since it can't be reused, it doesn't describe actual
hardware and it's just defeats purpose of DT by introducing
board-specific code.
There's another issue: if we introduce edp-connector we'll have to
specify power up delays somewhere (in dts? or in platform driver?), so
edp-connector doesn't really solve the issue of multiple panels with
same motherboard.
I'd say DT overlays should be preferred solution here, not another
connector binding.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 0:49 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-09 0:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Harald Geyer,
Thierry Reding, Thomas Gleixner, arm-linux, Icenowy Zheng
On Mon, Jul 1, 2019 at 2:58 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> > On 12.06.2019 17:20, Maxime Ripard wrote:
> > >> I am not sure if I understand whole discussion here, but I also do not
> > >> understand whole edp-connector thing.
> > > The context is this one:
> > > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> > > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> > >
> > > TL;DR: This bridge is being used on ARM laptops that can come with
> > > different eDP panels. Some of these panels require a regulator to be
> > > enabled for the panel to work, and this is obviously something that
> > > should be in the DT.
> > >
> > > However, we can't really describe the panel itself, since the vendor
> > > uses several of them and just relies on the eDP bus to do its job at
> > > retrieving the EDIDs. A generic panel isn't really working either
> > > since that would mean having a generic behaviour for all the panels
> > > connected to that bus, which isn't there either.
> > >
> > > The connector allows to expose this nicely.
> >
> > As VESA presentation says[1] eDP is based on DP but is much more
> > flexible, it is up to integrator (!!!) how the connection, power
> > up/down, initialization sequence should be performed. Trying to cover
> > every such case in edp-connector seems to me similar to panel-simple
> > attempt failure. Moreover there is no such thing as physical standard
> > eDP connector. Till now I though DT connector should describe physical
> > connector on the device, now I am lost, are there some DT bindings
> > guidelines about definition of a connector?
>
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.
>
> > Maybe instead of edp-connector one would introduce integrator's specific
> > connector, for example with compatible "olimex,teres-edp-connector"
> > which should follow edp abstract connector rules? This will be at least
> > consistent with below presentation[1] - eDP requirements depends on
> > integrator. Then if olimex has standard way of dealing with panels
> > present in olimex/teres platforms the driver would then create
> > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > Anyway it still looks fishy for me :), maybe because I am not
> > familiarized with details of these platforms.
>
> That makes sense yes
Actually, it makes no sense at all. Current implementation for anx6345
driver works fine as is with any panel specified assuming panel delays
are long enough for connected panel. It just doesn't use panel timings
from the driver. Creating a platform driver for connector itself looks
redundant since it can't be reused, it doesn't describe actual
hardware and it's just defeats purpose of DT by introducing
board-specific code.
There's another issue: if we introduce edp-connector we'll have to
specify power up delays somewhere (in dts? or in platform driver?), so
edp-connector doesn't really solve the issue of multiple panels with
same motherboard.
I'd say DT overlays should be preferred solution here, not another
connector binding.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 0:49 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-09 0:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
On Mon, Jul 1, 2019 at 2:58 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> Hi!
>
> On Fri, Jun 28, 2019 at 12:39:32PM +0200, Andrzej Hajda wrote:
> > On 12.06.2019 17:20, Maxime Ripard wrote:
> > >> I am not sure if I understand whole discussion here, but I also do not
> > >> understand whole edp-connector thing.
> > > The context is this one:
> > > https://patchwork.freedesktop.org/patch/257352/?series=51182&rev=1
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1
> > > https://patchwork.freedesktop.org/patch/286468/?series=56776&rev=2
> > >
> > > TL;DR: This bridge is being used on ARM laptops that can come with
> > > different eDP panels. Some of these panels require a regulator to be
> > > enabled for the panel to work, and this is obviously something that
> > > should be in the DT.
> > >
> > > However, we can't really describe the panel itself, since the vendor
> > > uses several of them and just relies on the eDP bus to do its job at
> > > retrieving the EDIDs. A generic panel isn't really working either
> > > since that would mean having a generic behaviour for all the panels
> > > connected to that bus, which isn't there either.
> > >
> > > The connector allows to expose this nicely.
> >
> > As VESA presentation says[1] eDP is based on DP but is much more
> > flexible, it is up to integrator (!!!) how the connection, power
> > up/down, initialization sequence should be performed. Trying to cover
> > every such case in edp-connector seems to me similar to panel-simple
> > attempt failure. Moreover there is no such thing as physical standard
> > eDP connector. Till now I though DT connector should describe physical
> > connector on the device, now I am lost, are there some DT bindings
> > guidelines about definition of a connector?
>
> This might be semantics but I guess we're in some kind of grey area?
>
> Like, for eDP, if it's soldered I guess we could say that there's no
> connector. But what happens if for some other board, that signal is
> routed through a ribbon?
>
> You could argue that there's no physical connector in both cases, or
> that there's one in both, or one for the ribbon and no connector for
> the one soldered in.
>
> > Maybe instead of edp-connector one would introduce integrator's specific
> > connector, for example with compatible "olimex,teres-edp-connector"
> > which should follow edp abstract connector rules? This will be at least
> > consistent with below presentation[1] - eDP requirements depends on
> > integrator. Then if olimex has standard way of dealing with panels
> > present in olimex/teres platforms the driver would then create
> > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > Anyway it still looks fishy for me :), maybe because I am not
> > familiarized with details of these platforms.
>
> That makes sense yes
Actually, it makes no sense at all. Current implementation for anx6345
driver works fine as is with any panel specified assuming panel delays
are long enough for connected panel. It just doesn't use panel timings
from the driver. Creating a platform driver for connector itself looks
redundant since it can't be reused, it doesn't describe actual
hardware and it's just defeats purpose of DT by introducing
board-specific code.
There's another issue: if we introduce edp-connector we'll have to
specify power up delays somewhere (in dts? or in platform driver?), so
edp-connector doesn't really solve the issue of multiple panels with
same motherboard.
I'd say DT overlays should be preferred solution here, not another
connector binding.
> 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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-09 0:49 ` Vasily Khoruzhick
(?)
@ 2019-07-09 8:55 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-09 8:55 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]
On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > Maybe instead of edp-connector one would introduce integrator's specific
> > > connector, for example with compatible "olimex,teres-edp-connector"
> > > which should follow edp abstract connector rules? This will be at least
> > > consistent with below presentation[1] - eDP requirements depends on
> > > integrator. Then if olimex has standard way of dealing with panels
> > > present in olimex/teres platforms the driver would then create
> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > Anyway it still looks fishy for me :), maybe because I am not
> > > familiarized with details of these platforms.
> >
> > That makes sense yes
>
> Actually, it makes no sense at all. Current implementation for anx6345
> driver works fine as is with any panel specified assuming panel delays
> are long enough for connected panel. It just doesn't use panel timings
> from the driver. Creating a platform driver for connector itself looks
> redundant since it can't be reused, it doesn't describe actual
> hardware and it's just defeats purpose of DT by introducing
> board-specific code.
I'm not sure where you got the idea that the purpose of DT is to not
have any board-specific code.
It's perfectly fine to have some, that's even why there's a compatible
assigned to each and every board.
What the DT is about is allowing us to have a generic behaviour that
we can detect: we can have a given behaviour for a given board, and a
separate one for another one, and this will be evaluated at runtime.
This is *exactly* what this is about: we can have a compatible that
sets a given, more specific, behaviour (olimex,teres-edp-connector)
while saying that this is compatible with the generic behaviour
(edp-connector). That way, any OS will know what quirk to apply if
needed, and if not that it can use the generic behaviour.
And we could create a generic driver, for the generic behaviour if
needed.
> There's another issue: if we introduce edp-connector we'll have to
> specify power up delays somewhere (in dts? or in platform driver?), so
> edp-connector doesn't really solve the issue of multiple panels with
> same motherboard.
And that's what that compatible is about :)
> I'd say DT overlays should be preferred solution here, not another
> connector binding.
Overlays are a way to apply a device tree dynamically. It's orthogonal
to the binding.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 8:55 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-09 8:55 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Harald Geyer,
Thierry Reding, Thomas Gleixner, arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 2554 bytes --]
On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > Maybe instead of edp-connector one would introduce integrator's specific
> > > connector, for example with compatible "olimex,teres-edp-connector"
> > > which should follow edp abstract connector rules? This will be at least
> > > consistent with below presentation[1] - eDP requirements depends on
> > > integrator. Then if olimex has standard way of dealing with panels
> > > present in olimex/teres platforms the driver would then create
> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > Anyway it still looks fishy for me :), maybe because I am not
> > > familiarized with details of these platforms.
> >
> > That makes sense yes
>
> Actually, it makes no sense at all. Current implementation for anx6345
> driver works fine as is with any panel specified assuming panel delays
> are long enough for connected panel. It just doesn't use panel timings
> from the driver. Creating a platform driver for connector itself looks
> redundant since it can't be reused, it doesn't describe actual
> hardware and it's just defeats purpose of DT by introducing
> board-specific code.
I'm not sure where you got the idea that the purpose of DT is to not
have any board-specific code.
It's perfectly fine to have some, that's even why there's a compatible
assigned to each and every board.
What the DT is about is allowing us to have a generic behaviour that
we can detect: we can have a given behaviour for a given board, and a
separate one for another one, and this will be evaluated at runtime.
This is *exactly* what this is about: we can have a compatible that
sets a given, more specific, behaviour (olimex,teres-edp-connector)
while saying that this is compatible with the generic behaviour
(edp-connector). That way, any OS will know what quirk to apply if
needed, and if not that it can use the generic behaviour.
And we could create a generic driver, for the generic behaviour if
needed.
> There's another issue: if we introduce edp-connector we'll have to
> specify power up delays somewhere (in dts? or in platform driver?), so
> edp-connector doesn't really solve the issue of multiple panels with
> same motherboard.
And that's what that compatible is about :)
> I'd say DT overlays should be preferred solution here, not another
> connector binding.
Overlays are a way to apply a device tree dynamically. It's orthogonal
to the binding.
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: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 8:55 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-09 8:55 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 2554 bytes --]
On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > Maybe instead of edp-connector one would introduce integrator's specific
> > > connector, for example with compatible "olimex,teres-edp-connector"
> > > which should follow edp abstract connector rules? This will be at least
> > > consistent with below presentation[1] - eDP requirements depends on
> > > integrator. Then if olimex has standard way of dealing with panels
> > > present in olimex/teres platforms the driver would then create
> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > Anyway it still looks fishy for me :), maybe because I am not
> > > familiarized with details of these platforms.
> >
> > That makes sense yes
>
> Actually, it makes no sense at all. Current implementation for anx6345
> driver works fine as is with any panel specified assuming panel delays
> are long enough for connected panel. It just doesn't use panel timings
> from the driver. Creating a platform driver for connector itself looks
> redundant since it can't be reused, it doesn't describe actual
> hardware and it's just defeats purpose of DT by introducing
> board-specific code.
I'm not sure where you got the idea that the purpose of DT is to not
have any board-specific code.
It's perfectly fine to have some, that's even why there's a compatible
assigned to each and every board.
What the DT is about is allowing us to have a generic behaviour that
we can detect: we can have a given behaviour for a given board, and a
separate one for another one, and this will be evaluated at runtime.
This is *exactly* what this is about: we can have a compatible that
sets a given, more specific, behaviour (olimex,teres-edp-connector)
while saying that this is compatible with the generic behaviour
(edp-connector). That way, any OS will know what quirk to apply if
needed, and if not that it can use the generic behaviour.
And we could create a generic driver, for the generic behaviour if
needed.
> There's another issue: if we introduce edp-connector we'll have to
> specify power up delays somewhere (in dts? or in platform driver?), so
> edp-connector doesn't really solve the issue of multiple panels with
> same motherboard.
And that's what that compatible is about :)
> I'd say DT overlays should be preferred solution here, not another
> connector binding.
Overlays are a way to apply a device tree dynamically. It's orthogonal
to the binding.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-09 8:55 ` Maxime Ripard
(?)
@ 2019-07-09 8:58 ` Icenowy Zheng
-1 siblings, 0 replies; 90+ messages in thread
From: Icenowy Zheng @ 2019-07-09 8:58 UTC (permalink / raw)
To: linux-arm-kernel, Maxime Ripard, Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
>On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
>> > > Maybe instead of edp-connector one would introduce integrator's
>specific
>> > > connector, for example with compatible
>"olimex,teres-edp-connector"
>> > > which should follow edp abstract connector rules? This will be at
>least
>> > > consistent with below presentation[1] - eDP requirements depends
>on
>> > > integrator. Then if olimex has standard way of dealing with
>panels
>> > > present in olimex/teres platforms the driver would then create
>> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I
>guess.
>> > > Anyway it still looks fishy for me :), maybe because I am not
>> > > familiarized with details of these platforms.
>> >
>> > That makes sense yes
>>
>> Actually, it makes no sense at all. Current implementation for
>anx6345
>> driver works fine as is with any panel specified assuming panel
>delays
>> are long enough for connected panel. It just doesn't use panel
>timings
>> from the driver. Creating a platform driver for connector itself
>looks
>> redundant since it can't be reused, it doesn't describe actual
>> hardware and it's just defeats purpose of DT by introducing
>> board-specific code.
>
>I'm not sure where you got the idea that the purpose of DT is to not
>have any board-specific code.
>
>It's perfectly fine to have some, that's even why there's a compatible
>assigned to each and every board.
>
>What the DT is about is allowing us to have a generic behaviour that
>we can detect: we can have a given behaviour for a given board, and a
>separate one for another one, and this will be evaluated at runtime.
>
>This is *exactly* what this is about: we can have a compatible that
>sets a given, more specific, behaviour (olimex,teres-edp-connector)
>while saying that this is compatible with the generic behaviour
>(edp-connector). That way, any OS will know what quirk to apply if
>needed, and if not that it can use the generic behaviour.
>
>And we could create a generic driver, for the generic behaviour if
>needed.
>
>> There's another issue: if we introduce edp-connector we'll have to
>> specify power up delays somewhere (in dts? or in platform driver?),
>so
>> edp-connector doesn't really solve the issue of multiple panels with
>> same motherboard.
>
>And that's what that compatible is about :)
Maybe we can introduce a connector w/o any driver just like hdmi-connector?
>
>> I'd say DT overlays should be preferred solution here, not another
>> connector binding.
>
>Overlays are a way to apply a device tree dynamically. It's orthogonal
>to the binding.
>
>Maxime
>
>--
>Maxime Ripard, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
--
使用 K-9 Mail 发送自我的Android设备。
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 8:58 ` Icenowy Zheng
0 siblings, 0 replies; 90+ messages in thread
From: Icenowy Zheng @ 2019-07-09 8:58 UTC (permalink / raw)
To: Maxime Ripard, Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
>On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
>> > > Maybe instead of edp-connector one would introduce integrator's
>specific
>> > > connector, for example with compatible
>"olimex,teres-edp-connector"
>> > > which should follow edp abstract connector rules? This will be at
>least
>> > > consistent with below presentation[1] - eDP requirements depends
>on
>> > > integrator. Then if olimex has standard way of dealing with
>panels
>> > > present in olimex/teres platforms the driver would then create
>> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I
>guess.
>> > > Anyway it still looks fishy for me :), maybe because I am not
>> > > familiarized with details of these platforms.
>> >
>> > That makes sense yes
>>
>> Actually, it makes no sense at all. Current implementation for
>anx6345
>> driver works fine as is with any panel specified assuming panel
>delays
>> are long enough for connected panel. It just doesn't use panel
>timings
>> from the driver. Creating a platform driver for connector itself
>looks
>> redundant since it can't be reused, it doesn't describe actual
>> hardware and it's just defeats purpose of DT by introducing
>> board-specific code.
>
>I'm not sure where you got the idea that the purpose of DT is to not
>have any board-specific code.
>
>It's perfectly fine to have some, that's even why there's a compatible
>assigned to each and every board.
>
>What the DT is about is allowing us to have a generic behaviour that
>we can detect: we can have a given behaviour for a given board, and a
>separate one for another one, and this will be evaluated at runtime.
>
>This is *exactly* what this is about: we can have a compatible that
>sets a given, more specific, behaviour (olimex,teres-edp-connector)
>while saying that this is compatible with the generic behaviour
>(edp-connector). That way, any OS will know what quirk to apply if
>needed, and if not that it can use the generic behaviour.
>
>And we could create a generic driver, for the generic behaviour if
>needed.
>
>> There's another issue: if we introduce edp-connector we'll have to
>> specify power up delays somewhere (in dts? or in platform driver?),
>so
>> edp-connector doesn't really solve the issue of multiple panels with
>> same motherboard.
>
>And that's what that compatible is about :)
Maybe we can introduce a connector w/o any driver just like hdmi-connector?
>
>> I'd say DT overlays should be preferred solution here, not another
>> connector binding.
>
>Overlays are a way to apply a device tree dynamically. It's orthogonal
>to the binding.
>
>Maxime
>
>--
>Maxime Ripard, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
--
使用 K-9 Mail 发送自我的Android设备。
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 8:58 ` Icenowy Zheng
0 siblings, 0 replies; 90+ messages in thread
From: Icenowy Zheng @ 2019-07-09 8:58 UTC (permalink / raw)
To: linux-arm-kernel, Maxime Ripard, Vasily Khoruzhick
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Andrzej Hajda, Chen-Yu Tsai,
Rob Herring, Sean Paul, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Thierry Reding, Torsten Duwe, Thomas Gleixner,
arm-linux
于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
>On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
>> > > Maybe instead of edp-connector one would introduce integrator's
>specific
>> > > connector, for example with compatible
>"olimex,teres-edp-connector"
>> > > which should follow edp abstract connector rules? This will be at
>least
>> > > consistent with below presentation[1] - eDP requirements depends
>on
>> > > integrator. Then if olimex has standard way of dealing with
>panels
>> > > present in olimex/teres platforms the driver would then create
>> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I
>guess.
>> > > Anyway it still looks fishy for me :), maybe because I am not
>> > > familiarized with details of these platforms.
>> >
>> > That makes sense yes
>>
>> Actually, it makes no sense at all. Current implementation for
>anx6345
>> driver works fine as is with any panel specified assuming panel
>delays
>> are long enough for connected panel. It just doesn't use panel
>timings
>> from the driver. Creating a platform driver for connector itself
>looks
>> redundant since it can't be reused, it doesn't describe actual
>> hardware and it's just defeats purpose of DT by introducing
>> board-specific code.
>
>I'm not sure where you got the idea that the purpose of DT is to not
>have any board-specific code.
>
>It's perfectly fine to have some, that's even why there's a compatible
>assigned to each and every board.
>
>What the DT is about is allowing us to have a generic behaviour that
>we can detect: we can have a given behaviour for a given board, and a
>separate one for another one, and this will be evaluated at runtime.
>
>This is *exactly* what this is about: we can have a compatible that
>sets a given, more specific, behaviour (olimex,teres-edp-connector)
>while saying that this is compatible with the generic behaviour
>(edp-connector). That way, any OS will know what quirk to apply if
>needed, and if not that it can use the generic behaviour.
>
>And we could create a generic driver, for the generic behaviour if
>needed.
>
>> There's another issue: if we introduce edp-connector we'll have to
>> specify power up delays somewhere (in dts? or in platform driver?),
>so
>> edp-connector doesn't really solve the issue of multiple panels with
>> same motherboard.
>
>And that's what that compatible is about :)
Maybe we can introduce a connector w/o any driver just like hdmi-connector?
>
>> I'd say DT overlays should be preferred solution here, not another
>> connector binding.
>
>Overlays are a way to apply a device tree dynamically. It's orthogonal
>to the binding.
>
>Maxime
>
>--
>Maxime Ripard, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
--
使用 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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-09 8:58 ` Icenowy Zheng
@ 2019-07-09 14:21 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-09 14:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-arm-kernel, Vasily Khoruzhick, Mark Rutland, devicetree,
Sean Paul, David Airlie, Greg Kroah-Hartman, linux-kernel,
dri-devel, Andrzej Hajda, Chen-Yu Tsai, Rob Herring,
Torsten Duwe, Laurent Pinchart, Daniel Vetter, Harald Geyer,
Thierry Reding, Thomas Gleixner
[-- Attachment #1: Type: text/plain, Size: 2962 bytes --]
On Tue, Jul 09, 2019 at 04:58:35PM +0800, Icenowy Zheng wrote:
>
>
> 于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
> >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> >> > > Maybe instead of edp-connector one would introduce integrator's
> >specific
> >> > > connector, for example with compatible
> >"olimex,teres-edp-connector"
> >> > > which should follow edp abstract connector rules? This will be at
> >least
> >> > > consistent with below presentation[1] - eDP requirements depends
> >on
> >> > > integrator. Then if olimex has standard way of dealing with
> >panels
> >> > > present in olimex/teres platforms the driver would then create
> >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I
> >guess.
> >> > > Anyway it still looks fishy for me :), maybe because I am not
> >> > > familiarized with details of these platforms.
> >> >
> >> > That makes sense yes
> >>
> >> Actually, it makes no sense at all. Current implementation for
> >anx6345
> >> driver works fine as is with any panel specified assuming panel
> >delays
> >> are long enough for connected panel. It just doesn't use panel
> >timings
> >> from the driver. Creating a platform driver for connector itself
> >looks
> >> redundant since it can't be reused, it doesn't describe actual
> >> hardware and it's just defeats purpose of DT by introducing
> >> board-specific code.
> >
> >I'm not sure where you got the idea that the purpose of DT is to not
> >have any board-specific code.
> >
> >It's perfectly fine to have some, that's even why there's a compatible
> >assigned to each and every board.
> >
> >What the DT is about is allowing us to have a generic behaviour that
> >we can detect: we can have a given behaviour for a given board, and a
> >separate one for another one, and this will be evaluated at runtime.
> >
> >This is *exactly* what this is about: we can have a compatible that
> >sets a given, more specific, behaviour (olimex,teres-edp-connector)
> >while saying that this is compatible with the generic behaviour
> >(edp-connector). That way, any OS will know what quirk to apply if
> >needed, and if not that it can use the generic behaviour.
> >
> >And we could create a generic driver, for the generic behaviour if
> >needed.
> >
> >> There's another issue: if we introduce edp-connector we'll have to
> >> specify power up delays somewhere (in dts? or in platform driver?),
> >so
> >> edp-connector doesn't really solve the issue of multiple panels with
> >> same motherboard.
> >
> >And that's what that compatible is about :)
>
> Maybe we can introduce a connector w/o any driver just like hdmi-connector?
Ironically, a driver for it has been sent yesterday :)
But yeah, we can definitely do that too.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 14:21 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-09 14:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Mark Rutland, devicetree, David Airlie, Greg Kroah-Hartman,
linux-kernel, dri-devel, Andrzej Hajda, Chen-Yu Tsai,
Rob Herring, Sean Paul, Laurent Pinchart, Daniel Vetter,
Harald Geyer, Thierry Reding, Torsten Duwe, Thomas Gleixner,
linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2962 bytes --]
On Tue, Jul 09, 2019 at 04:58:35PM +0800, Icenowy Zheng wrote:
>
>
> 于 2019年7月9日 GMT+08:00 下午4:55:32, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
> >On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> >> > > Maybe instead of edp-connector one would introduce integrator's
> >specific
> >> > > connector, for example with compatible
> >"olimex,teres-edp-connector"
> >> > > which should follow edp abstract connector rules? This will be at
> >least
> >> > > consistent with below presentation[1] - eDP requirements depends
> >on
> >> > > integrator. Then if olimex has standard way of dealing with
> >panels
> >> > > present in olimex/teres platforms the driver would then create
> >> > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I
> >guess.
> >> > > Anyway it still looks fishy for me :), maybe because I am not
> >> > > familiarized with details of these platforms.
> >> >
> >> > That makes sense yes
> >>
> >> Actually, it makes no sense at all. Current implementation for
> >anx6345
> >> driver works fine as is with any panel specified assuming panel
> >delays
> >> are long enough for connected panel. It just doesn't use panel
> >timings
> >> from the driver. Creating a platform driver for connector itself
> >looks
> >> redundant since it can't be reused, it doesn't describe actual
> >> hardware and it's just defeats purpose of DT by introducing
> >> board-specific code.
> >
> >I'm not sure where you got the idea that the purpose of DT is to not
> >have any board-specific code.
> >
> >It's perfectly fine to have some, that's even why there's a compatible
> >assigned to each and every board.
> >
> >What the DT is about is allowing us to have a generic behaviour that
> >we can detect: we can have a given behaviour for a given board, and a
> >separate one for another one, and this will be evaluated at runtime.
> >
> >This is *exactly* what this is about: we can have a compatible that
> >sets a given, more specific, behaviour (olimex,teres-edp-connector)
> >while saying that this is compatible with the generic behaviour
> >(edp-connector). That way, any OS will know what quirk to apply if
> >needed, and if not that it can use the generic behaviour.
> >
> >And we could create a generic driver, for the generic behaviour if
> >needed.
> >
> >> There's another issue: if we introduce edp-connector we'll have to
> >> specify power up delays somewhere (in dts? or in platform driver?),
> >so
> >> edp-connector doesn't really solve the issue of multiple panels with
> >> same motherboard.
> >
> >And that's what that compatible is about :)
>
> Maybe we can introduce a connector w/o any driver just like hdmi-connector?
Ironically, a driver for it has been sent yesterday :)
But yeah, we can definitely do that too.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-09 8:55 ` Maxime Ripard
(?)
@ 2019-07-09 20:30 ` Vasily Khoruzhick
-1 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-09 20:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > which should follow edp abstract connector rules? This will be at least
> > > > consistent with below presentation[1] - eDP requirements depends on
> > > > integrator. Then if olimex has standard way of dealing with panels
> > > > present in olimex/teres platforms the driver would then create
> > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > familiarized with details of these platforms.
> > >
> > > That makes sense yes
> >
> > Actually, it makes no sense at all. Current implementation for anx6345
> > driver works fine as is with any panel specified assuming panel delays
> > are long enough for connected panel. It just doesn't use panel timings
> > from the driver. Creating a platform driver for connector itself looks
> > redundant since it can't be reused, it doesn't describe actual
> > hardware and it's just defeats purpose of DT by introducing
> > board-specific code.
>
> I'm not sure where you got the idea that the purpose of DT is to not
> have any board-specific code.
I believe DT was an attempt to move to declarative approach for
describing hardware. Yes, we have different compatibles for different
devices but they're specific to particular device rather than
particular board. Device interconnection is described in DT along with
some properties rather than in board-specific C-file. Introducing
board-specific compatible for a connector isn't looking right to me.
> It's perfectly fine to have some, that's even why there's a compatible
> assigned to each and every board.
>
> What the DT is about is allowing us to have a generic behaviour that
> we can detect: we can have a given behaviour for a given board, and a
> separate one for another one, and this will be evaluated at runtime.
>
> This is *exactly* what this is about: we can have a compatible that
> sets a given, more specific, behaviour (olimex,teres-edp-connector)
> while saying that this is compatible with the generic behaviour
> (edp-connector). That way, any OS will know what quirk to apply if
> needed, and if not that it can use the generic behaviour.
>
> And we could create a generic driver, for the generic behaviour if
> needed.
>
> > There's another issue: if we introduce edp-connector we'll have to
> > specify power up delays somewhere (in dts? or in platform driver?), so
> > edp-connector doesn't really solve the issue of multiple panels with
> > same motherboard.
>
> And that's what that compatible is about :)
Sorry, I fail to see how it would be different from using existing
panels infrastructure and different panels compatibles. I think Rob's
idea was to introduce generic edp-connector. If we can't make it
generic then let's use panel infrastructure.
> > I'd say DT overlays should be preferred solution here, not another
> > connector binding.
>
> Overlays are a way to apply a device tree dynamically. It's orthogonal
> to the binding.
It isn't orthogonal to original problem though.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 20:30 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-09 20:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Harald Geyer,
Thierry Reding, Thomas Gleixner, arm-linux, Icenowy Zheng
On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > which should follow edp abstract connector rules? This will be at least
> > > > consistent with below presentation[1] - eDP requirements depends on
> > > > integrator. Then if olimex has standard way of dealing with panels
> > > > present in olimex/teres platforms the driver would then create
> > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > familiarized with details of these platforms.
> > >
> > > That makes sense yes
> >
> > Actually, it makes no sense at all. Current implementation for anx6345
> > driver works fine as is with any panel specified assuming panel delays
> > are long enough for connected panel. It just doesn't use panel timings
> > from the driver. Creating a platform driver for connector itself looks
> > redundant since it can't be reused, it doesn't describe actual
> > hardware and it's just defeats purpose of DT by introducing
> > board-specific code.
>
> I'm not sure where you got the idea that the purpose of DT is to not
> have any board-specific code.
I believe DT was an attempt to move to declarative approach for
describing hardware. Yes, we have different compatibles for different
devices but they're specific to particular device rather than
particular board. Device interconnection is described in DT along with
some properties rather than in board-specific C-file. Introducing
board-specific compatible for a connector isn't looking right to me.
> It's perfectly fine to have some, that's even why there's a compatible
> assigned to each and every board.
>
> What the DT is about is allowing us to have a generic behaviour that
> we can detect: we can have a given behaviour for a given board, and a
> separate one for another one, and this will be evaluated at runtime.
>
> This is *exactly* what this is about: we can have a compatible that
> sets a given, more specific, behaviour (olimex,teres-edp-connector)
> while saying that this is compatible with the generic behaviour
> (edp-connector). That way, any OS will know what quirk to apply if
> needed, and if not that it can use the generic behaviour.
>
> And we could create a generic driver, for the generic behaviour if
> needed.
>
> > There's another issue: if we introduce edp-connector we'll have to
> > specify power up delays somewhere (in dts? or in platform driver?), so
> > edp-connector doesn't really solve the issue of multiple panels with
> > same motherboard.
>
> And that's what that compatible is about :)
Sorry, I fail to see how it would be different from using existing
panels infrastructure and different panels compatibles. I think Rob's
idea was to introduce generic edp-connector. If we can't make it
generic then let's use panel infrastructure.
> > I'd say DT overlays should be preferred solution here, not another
> > connector binding.
>
> Overlays are a way to apply a device tree dynamically. It's orthogonal
> to the binding.
It isn't orthogonal to original problem though.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-09 20:30 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-09 20:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > which should follow edp abstract connector rules? This will be at least
> > > > consistent with below presentation[1] - eDP requirements depends on
> > > > integrator. Then if olimex has standard way of dealing with panels
> > > > present in olimex/teres platforms the driver would then create
> > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > familiarized with details of these platforms.
> > >
> > > That makes sense yes
> >
> > Actually, it makes no sense at all. Current implementation for anx6345
> > driver works fine as is with any panel specified assuming panel delays
> > are long enough for connected panel. It just doesn't use panel timings
> > from the driver. Creating a platform driver for connector itself looks
> > redundant since it can't be reused, it doesn't describe actual
> > hardware and it's just defeats purpose of DT by introducing
> > board-specific code.
>
> I'm not sure where you got the idea that the purpose of DT is to not
> have any board-specific code.
I believe DT was an attempt to move to declarative approach for
describing hardware. Yes, we have different compatibles for different
devices but they're specific to particular device rather than
particular board. Device interconnection is described in DT along with
some properties rather than in board-specific C-file. Introducing
board-specific compatible for a connector isn't looking right to me.
> It's perfectly fine to have some, that's even why there's a compatible
> assigned to each and every board.
>
> What the DT is about is allowing us to have a generic behaviour that
> we can detect: we can have a given behaviour for a given board, and a
> separate one for another one, and this will be evaluated at runtime.
>
> This is *exactly* what this is about: we can have a compatible that
> sets a given, more specific, behaviour (olimex,teres-edp-connector)
> while saying that this is compatible with the generic behaviour
> (edp-connector). That way, any OS will know what quirk to apply if
> needed, and if not that it can use the generic behaviour.
>
> And we could create a generic driver, for the generic behaviour if
> needed.
>
> > There's another issue: if we introduce edp-connector we'll have to
> > specify power up delays somewhere (in dts? or in platform driver?), so
> > edp-connector doesn't really solve the issue of multiple panels with
> > same motherboard.
>
> And that's what that compatible is about :)
Sorry, I fail to see how it would be different from using existing
panels infrastructure and different panels compatibles. I think Rob's
idea was to introduce generic edp-connector. If we can't make it
generic then let's use panel infrastructure.
> > I'd say DT overlays should be preferred solution here, not another
> > connector binding.
>
> Overlays are a way to apply a device tree dynamically. It's orthogonal
> to the binding.
It isn't orthogonal to original problem though.
> 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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-09 20:30 ` Vasily Khoruzhick
@ 2019-07-10 11:40 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-10 11:40 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4619 bytes --]
On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote:
> On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > > which should follow edp abstract connector rules? This will be at least
> > > > > consistent with below presentation[1] - eDP requirements depends on
> > > > > integrator. Then if olimex has standard way of dealing with panels
> > > > > present in olimex/teres platforms the driver would then create
> > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > > familiarized with details of these platforms.
> > > >
> > > > That makes sense yes
> > >
> > > Actually, it makes no sense at all. Current implementation for anx6345
> > > driver works fine as is with any panel specified assuming panel delays
> > > are long enough for connected panel. It just doesn't use panel timings
> > > from the driver. Creating a platform driver for connector itself looks
> > > redundant since it can't be reused, it doesn't describe actual
> > > hardware and it's just defeats purpose of DT by introducing
> > > board-specific code.
> >
> > I'm not sure where you got the idea that the purpose of DT is to not
> > have any board-specific code.
>
> I believe DT was an attempt to move to declarative approach for
> describing hardware. Yes, we have different compatibles for different
> devices but they're specific to particular device rather than
> particular board. Device interconnection is described in DT along with
> some properties rather than in board-specific C-file.
You're right, but it's not incompatible with having some code to deal
with some board quirk.
> Introducing board-specific compatible for a connector isn't looking
> right to me.
If that board has a board-specific behaviour for it's connector, then
what's the issue?
You can't describe all the quirks in the all boards using purely
properties.
> > It's perfectly fine to have some, that's even why there's a compatible
> > assigned to each and every board.
> >
> > What the DT is about is allowing us to have a generic behaviour that
> > we can detect: we can have a given behaviour for a given board, and a
> > separate one for another one, and this will be evaluated at runtime.
> >
> > This is *exactly* what this is about: we can have a compatible that
> > sets a given, more specific, behaviour (olimex,teres-edp-connector)
> > while saying that this is compatible with the generic behaviour
> > (edp-connector). That way, any OS will know what quirk to apply if
> > needed, and if not that it can use the generic behaviour.
> >
> > And we could create a generic driver, for the generic behaviour if
> > needed.
> >
> > > There's another issue: if we introduce edp-connector we'll have to
> > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > edp-connector doesn't really solve the issue of multiple panels with
> > > same motherboard.
> >
> > And that's what that compatible is about :)
>
> Sorry, I fail to see how it would be different from using existing
> panels infrastructure and different panels compatibles. I think Rob's
> idea was to introduce generic edp-connector.
Again, there's no such thing as a generic edp-connector. The spec
doesn't define anything related to the power sequence for example.
> If we can't make it generic then let's use panel infrastructure.
Which uses a device specific compatible. Really, I'm not sure what
your objection and / or argument is here.
In addition, when that was brought up in the discussion, you rejected
it because it was inconvenient:
https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
And I agree with you on that one.
> > > I'd say DT overlays should be preferred solution here, not another
> > > connector binding.
> >
> > Overlays are a way to apply a device tree dynamically. It's orthogonal
> > to the binding.
>
> It isn't orthogonal to original problem though.
It is. The original problem is that you want to power up whatever is
on the other side of a eDP link using an arbitrary regulator.
This is a "how do I describe that in my DT" problem, and it really has
nothing to do with how the DT is being passed to the kernel.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-10 11:40 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-10 11:40 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 4619 bytes --]
On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote:
> On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > > which should follow edp abstract connector rules? This will be at least
> > > > > consistent with below presentation[1] - eDP requirements depends on
> > > > > integrator. Then if olimex has standard way of dealing with panels
> > > > > present in olimex/teres platforms the driver would then create
> > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > > familiarized with details of these platforms.
> > > >
> > > > That makes sense yes
> > >
> > > Actually, it makes no sense at all. Current implementation for anx6345
> > > driver works fine as is with any panel specified assuming panel delays
> > > are long enough for connected panel. It just doesn't use panel timings
> > > from the driver. Creating a platform driver for connector itself looks
> > > redundant since it can't be reused, it doesn't describe actual
> > > hardware and it's just defeats purpose of DT by introducing
> > > board-specific code.
> >
> > I'm not sure where you got the idea that the purpose of DT is to not
> > have any board-specific code.
>
> I believe DT was an attempt to move to declarative approach for
> describing hardware. Yes, we have different compatibles for different
> devices but they're specific to particular device rather than
> particular board. Device interconnection is described in DT along with
> some properties rather than in board-specific C-file.
You're right, but it's not incompatible with having some code to deal
with some board quirk.
> Introducing board-specific compatible for a connector isn't looking
> right to me.
If that board has a board-specific behaviour for it's connector, then
what's the issue?
You can't describe all the quirks in the all boards using purely
properties.
> > It's perfectly fine to have some, that's even why there's a compatible
> > assigned to each and every board.
> >
> > What the DT is about is allowing us to have a generic behaviour that
> > we can detect: we can have a given behaviour for a given board, and a
> > separate one for another one, and this will be evaluated at runtime.
> >
> > This is *exactly* what this is about: we can have a compatible that
> > sets a given, more specific, behaviour (olimex,teres-edp-connector)
> > while saying that this is compatible with the generic behaviour
> > (edp-connector). That way, any OS will know what quirk to apply if
> > needed, and if not that it can use the generic behaviour.
> >
> > And we could create a generic driver, for the generic behaviour if
> > needed.
> >
> > > There's another issue: if we introduce edp-connector we'll have to
> > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > edp-connector doesn't really solve the issue of multiple panels with
> > > same motherboard.
> >
> > And that's what that compatible is about :)
>
> Sorry, I fail to see how it would be different from using existing
> panels infrastructure and different panels compatibles. I think Rob's
> idea was to introduce generic edp-connector.
Again, there's no such thing as a generic edp-connector. The spec
doesn't define anything related to the power sequence for example.
> If we can't make it generic then let's use panel infrastructure.
Which uses a device specific compatible. Really, I'm not sure what
your objection and / or argument is here.
In addition, when that was brought up in the discussion, you rejected
it because it was inconvenient:
https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
And I agree with you on that one.
> > > I'd say DT overlays should be preferred solution here, not another
> > > connector binding.
> >
> > Overlays are a way to apply a device tree dynamically. It's orthogonal
> > to the binding.
>
> It isn't orthogonal to original problem though.
It is. The original problem is that you want to power up whatever is
on the other side of a eDP link using an arbitrary regulator.
This is a "how do I describe that in my DT" problem, and it really has
nothing to do with how the DT is being passed to the kernel.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-10 11:40 ` Maxime Ripard
@ 2019-07-10 22:11 ` Vasily Khoruzhick
-1 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-10 22:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote:
> > On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > > > which should follow edp abstract connector rules? This will be at least
> > > > > > consistent with below presentation[1] - eDP requirements depends on
> > > > > > integrator. Then if olimex has standard way of dealing with panels
> > > > > > present in olimex/teres platforms the driver would then create
> > > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > > > familiarized with details of these platforms.
> > > > >
> > > > > That makes sense yes
> > > >
> > > > Actually, it makes no sense at all. Current implementation for anx6345
> > > > driver works fine as is with any panel specified assuming panel delays
> > > > are long enough for connected panel. It just doesn't use panel timings
> > > > from the driver. Creating a platform driver for connector itself looks
> > > > redundant since it can't be reused, it doesn't describe actual
> > > > hardware and it's just defeats purpose of DT by introducing
> > > > board-specific code.
> > >
> > > I'm not sure where you got the idea that the purpose of DT is to not
> > > have any board-specific code.
> >
> > I believe DT was an attempt to move to declarative approach for
> > describing hardware. Yes, we have different compatibles for different
> > devices but they're specific to particular device rather than
> > particular board. Device interconnection is described in DT along with
> > some properties rather than in board-specific C-file.
>
> You're right, but it's not incompatible with having some code to deal
> with some board quirk.
>
> > Introducing board-specific compatible for a connector isn't looking
> > right to me.
>
> If that board has a board-specific behaviour for it's connector, then
> what's the issue?
>
> You can't describe all the quirks in the all boards using purely
> properties.
>
> > > It's perfectly fine to have some, that's even why there's a compatible
> > > assigned to each and every board.
> > >
> > > What the DT is about is allowing us to have a generic behaviour that
> > > we can detect: we can have a given behaviour for a given board, and a
> > > separate one for another one, and this will be evaluated at runtime.
> > >
> > > This is *exactly* what this is about: we can have a compatible that
> > > sets a given, more specific, behaviour (olimex,teres-edp-connector)
> > > while saying that this is compatible with the generic behaviour
> > > (edp-connector). That way, any OS will know what quirk to apply if
> > > needed, and if not that it can use the generic behaviour.
> > >
> > > And we could create a generic driver, for the generic behaviour if
> > > needed.
> > >
> > > > There's another issue: if we introduce edp-connector we'll have to
> > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > same motherboard.
> > >
> > > And that's what that compatible is about :)
> >
> > Sorry, I fail to see how it would be different from using existing
> > panels infrastructure and different panels compatibles. I think Rob's
> > idea was to introduce generic edp-connector.
>
> Again, there's no such thing as a generic edp-connector. The spec
> doesn't define anything related to the power sequence for example.
>
> > If we can't make it generic then let's use panel infrastructure.
>
> Which uses a device specific compatible. Really, I'm not sure what
> your objection and / or argument is here.
>
> In addition, when that was brought up in the discussion, you rejected
> it because it was inconvenient:
> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
It is inconvenient, but I don't understand how having board-specific
connectors fixes it.
> And I agree with you on that one.
>
> > > > I'd say DT overlays should be preferred solution here, not another
> > > > connector binding.
> > >
> > > Overlays are a way to apply a device tree dynamically. It's orthogonal
> > > to the binding.
> >
> > It isn't orthogonal to original problem though.
>
> It is. The original problem is that you want to power up whatever is
> on the other side of a eDP link using an arbitrary regulator.
>
> This is a "how do I describe that in my DT" problem, and it really has
> nothing to do with how the DT is being passed to the kernel.
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-10 22:11 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-10 22:11 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Tue, Jul 09, 2019 at 01:30:18PM -0700, Vasily Khoruzhick wrote:
> > On Tue, Jul 9, 2019 at 1:55 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Mon, Jul 08, 2019 at 05:49:21PM -0700, Vasily Khoruzhick wrote:
> > > > > > Maybe instead of edp-connector one would introduce integrator's specific
> > > > > > connector, for example with compatible "olimex,teres-edp-connector"
> > > > > > which should follow edp abstract connector rules? This will be at least
> > > > > > consistent with below presentation[1] - eDP requirements depends on
> > > > > > integrator. Then if olimex has standard way of dealing with panels
> > > > > > present in olimex/teres platforms the driver would then create
> > > > > > drm_panel/drm_connector/drm_bridge(?) according to these rules, I guess.
> > > > > > Anyway it still looks fishy for me :), maybe because I am not
> > > > > > familiarized with details of these platforms.
> > > > >
> > > > > That makes sense yes
> > > >
> > > > Actually, it makes no sense at all. Current implementation for anx6345
> > > > driver works fine as is with any panel specified assuming panel delays
> > > > are long enough for connected panel. It just doesn't use panel timings
> > > > from the driver. Creating a platform driver for connector itself looks
> > > > redundant since it can't be reused, it doesn't describe actual
> > > > hardware and it's just defeats purpose of DT by introducing
> > > > board-specific code.
> > >
> > > I'm not sure where you got the idea that the purpose of DT is to not
> > > have any board-specific code.
> >
> > I believe DT was an attempt to move to declarative approach for
> > describing hardware. Yes, we have different compatibles for different
> > devices but they're specific to particular device rather than
> > particular board. Device interconnection is described in DT along with
> > some properties rather than in board-specific C-file.
>
> You're right, but it's not incompatible with having some code to deal
> with some board quirk.
>
> > Introducing board-specific compatible for a connector isn't looking
> > right to me.
>
> If that board has a board-specific behaviour for it's connector, then
> what's the issue?
>
> You can't describe all the quirks in the all boards using purely
> properties.
>
> > > It's perfectly fine to have some, that's even why there's a compatible
> > > assigned to each and every board.
> > >
> > > What the DT is about is allowing us to have a generic behaviour that
> > > we can detect: we can have a given behaviour for a given board, and a
> > > separate one for another one, and this will be evaluated at runtime.
> > >
> > > This is *exactly* what this is about: we can have a compatible that
> > > sets a given, more specific, behaviour (olimex,teres-edp-connector)
> > > while saying that this is compatible with the generic behaviour
> > > (edp-connector). That way, any OS will know what quirk to apply if
> > > needed, and if not that it can use the generic behaviour.
> > >
> > > And we could create a generic driver, for the generic behaviour if
> > > needed.
> > >
> > > > There's another issue: if we introduce edp-connector we'll have to
> > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > same motherboard.
> > >
> > > And that's what that compatible is about :)
> >
> > Sorry, I fail to see how it would be different from using existing
> > panels infrastructure and different panels compatibles. I think Rob's
> > idea was to introduce generic edp-connector.
>
> Again, there's no such thing as a generic edp-connector. The spec
> doesn't define anything related to the power sequence for example.
>
> > If we can't make it generic then let's use panel infrastructure.
>
> Which uses a device specific compatible. Really, I'm not sure what
> your objection and / or argument is here.
>
> In addition, when that was brought up in the discussion, you rejected
> it because it was inconvenient:
> https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
It is inconvenient, but I don't understand how having board-specific
connectors fixes it.
> And I agree with you on that one.
>
> > > > I'd say DT overlays should be preferred solution here, not another
> > > > connector binding.
> > >
> > > Overlays are a way to apply a device tree dynamically. It's orthogonal
> > > to the binding.
> >
> > It isn't orthogonal to original problem though.
>
> It is. The original problem is that you want to power up whatever is
> on the other side of a eDP link using an arbitrary regulator.
>
> This is a "how do I describe that in my DT" problem, and it really has
> nothing to do with how the DT is being passed to the kernel.
>
> 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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-10 22:11 ` Vasily Khoruzhick
@ 2019-07-12 20:15 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-12 20:15 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > same motherboard.
> > > >
> > > > And that's what that compatible is about :)
> > >
> > > Sorry, I fail to see how it would be different from using existing
> > > panels infrastructure and different panels compatibles. I think Rob's
> > > idea was to introduce generic edp-connector.
> >
> > Again, there's no such thing as a generic edp-connector. The spec
> > doesn't define anything related to the power sequence for example.
> >
> > > If we can't make it generic then let's use panel infrastructure.
> >
> > Which uses a device specific compatible. Really, I'm not sure what
> > your objection and / or argument is here.
> >
> > In addition, when that was brought up in the discussion, you rejected
> > it because it was inconvenient:
> > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
>
> It is inconvenient, but I don't understand how having board-specific
> connectors fixes it.
How it would not fix it?
You'll have one connector, without the need to describe each and every
panel in the device tree and rely on the EDID instead, and you'll have
the option to power up the regulator you need.
I really don't understand what's the issue here, so let's take a step
back. What are is the issue , what are your requirements, and how
would you like that to be described ?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-12 20:15 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-12 20:15 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > same motherboard.
> > > >
> > > > And that's what that compatible is about :)
> > >
> > > Sorry, I fail to see how it would be different from using existing
> > > panels infrastructure and different panels compatibles. I think Rob's
> > > idea was to introduce generic edp-connector.
> >
> > Again, there's no such thing as a generic edp-connector. The spec
> > doesn't define anything related to the power sequence for example.
> >
> > > If we can't make it generic then let's use panel infrastructure.
> >
> > Which uses a device specific compatible. Really, I'm not sure what
> > your objection and / or argument is here.
> >
> > In addition, when that was brought up in the discussion, you rejected
> > it because it was inconvenient:
> > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
>
> It is inconvenient, but I don't understand how having board-specific
> connectors fixes it.
How it would not fix it?
You'll have one connector, without the need to describe each and every
panel in the device tree and rely on the EDID instead, and you'll have
the option to power up the regulator you need.
I really don't understand what's the issue here, so let's take a step
back. What are is the issue , what are your requirements, and how
would you like that to be described ?
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-12 20:15 ` Maxime Ripard
(?)
@ 2019-07-16 0:28 ` Vasily Khoruzhick
-1 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-16 0:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > > same motherboard.
> > > > >
> > > > > And that's what that compatible is about :)
> > > >
> > > > Sorry, I fail to see how it would be different from using existing
> > > > panels infrastructure and different panels compatibles. I think Rob's
> > > > idea was to introduce generic edp-connector.
> > >
> > > Again, there's no such thing as a generic edp-connector. The spec
> > > doesn't define anything related to the power sequence for example.
> > >
> > > > If we can't make it generic then let's use panel infrastructure.
> > >
> > > Which uses a device specific compatible. Really, I'm not sure what
> > > your objection and / or argument is here.
> > >
> > > In addition, when that was brought up in the discussion, you rejected
> > > it because it was inconvenient:
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
> >
> > It is inconvenient, but I don't understand how having board-specific
> > connectors fixes it.
>
> How it would not fix it?
I think I got your idea, but yet I think it's not the best solution.
Do I understand correctly that you're proposing to introduce
board-specific edp-connector driver that will be aware of worst case
power up delays and will control backlight and power?
Then why not to add another board-specific panel (e.g.
"pine64,pinebook-panel") to simple-panel.c that does the same?
> You'll have one connector, without the need to describe each and every
> panel in the device tree and rely on the EDID instead, and you'll have
> the option to power up the regulator you need.
>
> I really don't understand what's the issue here, so let's take a step
> back. What are is the issue , what are your requirements, and how
> would you like that to be described ?
We have a device (Pinebook) that uses the same board with multiple edp
panels. So far there're pinebooks with 3 different panels: 11" with
768p panel, 11" with 1080p panel, 14" with 768p panel.
Currently there's no way to describe all pinebooks with a single dts.
There's a simple workaround though -- we can just specify a panel with
worst power up delays in dts and it'll work since anx6345 driver
ignores panel modes anyway and uses EDID.
Originally I proposed to extend simple-panel driver to support generic
edp-panel but it was rejected. I still believe that it's the best
solution assuming we can specify delays in dts, since panels list is
specific to particular device and it probably can't be reused, i.e.
there's no good reason to move it into C code.
Rob Herring proposed to introduce edp-connector. While I still believe
that it's not accurate description of hardware since it'll have to
have backlight node (backlight is actually panel property) I was OK
with this approach assuming we can store delays in dts.
Later it evolved into board-specific edp-connector.
So far I don't understand why everyone is trying to avoid introducing
edp-panel driver that can read delays from dts. Basically, I don't
understand what's the magic behind simple-panel.c and why new panels
should be added there rather than described in dts. [1] Doesn't
explain that.
[1] http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html
Regards,
Vasily
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-16 0:28 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-16 0:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Chen-Yu Tsai,
Rob Herring, Torsten Duwe, Laurent Pinchart, Harald Geyer,
Thierry Reding, Thomas Gleixner, arm-linux, Icenowy Zheng
On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > > same motherboard.
> > > > >
> > > > > And that's what that compatible is about :)
> > > >
> > > > Sorry, I fail to see how it would be different from using existing
> > > > panels infrastructure and different panels compatibles. I think Rob's
> > > > idea was to introduce generic edp-connector.
> > >
> > > Again, there's no such thing as a generic edp-connector. The spec
> > > doesn't define anything related to the power sequence for example.
> > >
> > > > If we can't make it generic then let's use panel infrastructure.
> > >
> > > Which uses a device specific compatible. Really, I'm not sure what
> > > your objection and / or argument is here.
> > >
> > > In addition, when that was brought up in the discussion, you rejected
> > > it because it was inconvenient:
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
> >
> > It is inconvenient, but I don't understand how having board-specific
> > connectors fixes it.
>
> How it would not fix it?
I think I got your idea, but yet I think it's not the best solution.
Do I understand correctly that you're proposing to introduce
board-specific edp-connector driver that will be aware of worst case
power up delays and will control backlight and power?
Then why not to add another board-specific panel (e.g.
"pine64,pinebook-panel") to simple-panel.c that does the same?
> You'll have one connector, without the need to describe each and every
> panel in the device tree and rely on the EDID instead, and you'll have
> the option to power up the regulator you need.
>
> I really don't understand what's the issue here, so let's take a step
> back. What are is the issue , what are your requirements, and how
> would you like that to be described ?
We have a device (Pinebook) that uses the same board with multiple edp
panels. So far there're pinebooks with 3 different panels: 11" with
768p panel, 11" with 1080p panel, 14" with 768p panel.
Currently there's no way to describe all pinebooks with a single dts.
There's a simple workaround though -- we can just specify a panel with
worst power up delays in dts and it'll work since anx6345 driver
ignores panel modes anyway and uses EDID.
Originally I proposed to extend simple-panel driver to support generic
edp-panel but it was rejected. I still believe that it's the best
solution assuming we can specify delays in dts, since panels list is
specific to particular device and it probably can't be reused, i.e.
there's no good reason to move it into C code.
Rob Herring proposed to introduce edp-connector. While I still believe
that it's not accurate description of hardware since it'll have to
have backlight node (backlight is actually panel property) I was OK
with this approach assuming we can store delays in dts.
Later it evolved into board-specific edp-connector.
So far I don't understand why everyone is trying to avoid introducing
edp-panel driver that can read delays from dts. Basically, I don't
understand what's the magic behind simple-panel.c and why new panels
should be added there rather than described in dts. [1] Doesn't
explain that.
[1] http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html
Regards,
Vasily
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-16 0:28 ` Vasily Khoruzhick
0 siblings, 0 replies; 90+ messages in thread
From: Vasily Khoruzhick @ 2019-07-16 0:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > > same motherboard.
> > > > >
> > > > > And that's what that compatible is about :)
> > > >
> > > > Sorry, I fail to see how it would be different from using existing
> > > > panels infrastructure and different panels compatibles. I think Rob's
> > > > idea was to introduce generic edp-connector.
> > >
> > > Again, there's no such thing as a generic edp-connector. The spec
> > > doesn't define anything related to the power sequence for example.
> > >
> > > > If we can't make it generic then let's use panel infrastructure.
> > >
> > > Which uses a device specific compatible. Really, I'm not sure what
> > > your objection and / or argument is here.
> > >
> > > In addition, when that was brought up in the discussion, you rejected
> > > it because it was inconvenient:
> > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
> >
> > It is inconvenient, but I don't understand how having board-specific
> > connectors fixes it.
>
> How it would not fix it?
I think I got your idea, but yet I think it's not the best solution.
Do I understand correctly that you're proposing to introduce
board-specific edp-connector driver that will be aware of worst case
power up delays and will control backlight and power?
Then why not to add another board-specific panel (e.g.
"pine64,pinebook-panel") to simple-panel.c that does the same?
> You'll have one connector, without the need to describe each and every
> panel in the device tree and rely on the EDID instead, and you'll have
> the option to power up the regulator you need.
>
> I really don't understand what's the issue here, so let's take a step
> back. What are is the issue , what are your requirements, and how
> would you like that to be described ?
We have a device (Pinebook) that uses the same board with multiple edp
panels. So far there're pinebooks with 3 different panels: 11" with
768p panel, 11" with 1080p panel, 14" with 768p panel.
Currently there's no way to describe all pinebooks with a single dts.
There's a simple workaround though -- we can just specify a panel with
worst power up delays in dts and it'll work since anx6345 driver
ignores panel modes anyway and uses EDID.
Originally I proposed to extend simple-panel driver to support generic
edp-panel but it was rejected. I still believe that it's the best
solution assuming we can specify delays in dts, since panels list is
specific to particular device and it probably can't be reused, i.e.
there's no good reason to move it into C code.
Rob Herring proposed to introduce edp-connector. While I still believe
that it's not accurate description of hardware since it'll have to
have backlight node (backlight is actually panel property) I was OK
with this approach assuming we can store delays in dts.
Later it evolved into board-specific edp-connector.
So far I don't understand why everyone is trying to avoid introducing
edp-panel driver that can read delays from dts. Basically, I don't
understand what's the magic behind simple-panel.c and why new panels
should be added there rather than described in dts. [1] Doesn't
explain that.
[1] http://sietch-tagr.blogspot.com/2016/04/display-panels-are-not-special.html
Regards,
Vasily
> 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] 90+ messages in thread
* Re: [PATCH v2 5/7] drm/bridge: Add Analogix anx6345 support
2019-06-12 9:13 ` Andrzej Hajda
@ 2019-07-18 16:42 ` Torsten Duwe
-1 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-07-18 16:42 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, Mark Rutland,
Thierry Reding, David Airlie, Daniel Vetter, Laurent Pinchart,
Icenowy Zheng, Sean Paul, Vasily Khoruzhick, Harald Geyer,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
linux-arm-kernel, linux-kernel
On Wed, Jun 12, 2019 at 11:13:10AM +0200, Andrzej Hajda wrote:
> On 04.06.2019 14:23, Torsten Duwe wrote:
> > +
> > +static void anx6345_poweron(struct anx6345 *anx6345)
> > +{
> > + int err;
> > +
> > + /* Ensure reset is asserted before starting power on sequence */
> > + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
>
> With fixed devm_gpiod_get below this line can be removed.
In any case, reset must be asserted for this procedure to succeed...
> > +static enum drm_mode_status
> > +anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode)
> > +{
> > + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > + return MODE_NO_INTERLACE;
> > +
> > + /* Max 1200p at 5.4 Ghz, one lane */
> > + if (mode->clock > 154000)
> > + return MODE_CLOCK_HIGH;
>
> I wonder if you shouldn't take into account training results here, ie.
> training perfrormed before validation.
Sure, but this is verbatim from the anx78xx.c sibling, code provided
by analogix. Lacking in-depth datasheets, this is probably the best effort.
> > +
> > + /* 2.5V digital core power regulator */
> > + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
> > + if (IS_ERR(anx6345->dvdd25)) {
> > + DRM_ERROR("dvdd25-supply not found\n");
> > + return PTR_ERR(anx6345->dvdd25);
> > + }
> > +
> > + /* GPIO for chip reset */
> > + anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
>
> Shouldn't be set to GPIOD_OUT_HIGH?
It used to be in the original submission, and confused even more people ;-)
Fact is, the reset for this chip _is_ low active; I'm following
Documentation/devicetree/bindings/gpio/gpio.txt, "1.1) GPIO specifier
best practices", which I find rather comprehensive.
Any suggestions on how to phrase this even better are appreciated.
> > +};
> > +module_i2c_driver(anx6345_driver);
> > +
> > +MODULE_DESCRIPTION("ANX6345 eDP Transmitter driver");
> > +MODULE_AUTHOR("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
>
> Submitter, patch author, and module author are different, this can be
> correct, but maybe somebody forgot to update some of these fields.
As mentioned in the v2 cover letter, I had a closer look on which code got
actually introduced and which lines were simply copied around, and made the
copyright and authorship stick to where they belong. *I* believe this is
correct now; specific improvements welcome.
Torsten
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 5/7] drm/bridge: Add Analogix anx6345 support
@ 2019-07-18 16:42 ` Torsten Duwe
0 siblings, 0 replies; 90+ messages in thread
From: Torsten Duwe @ 2019-07-18 16:42 UTC (permalink / raw)
To: Andrzej Hajda
Cc: Mark Rutland, devicetree, Maxime Ripard, Greg Kroah-Hartman,
linux-kernel, dri-devel, David Airlie, Chen-Yu Tsai, Rob Herring,
Thierry Reding, Laurent Pinchart, Daniel Vetter, Harald Geyer,
Sean Paul, Thomas Gleixner, linux-arm-kernel, Icenowy Zheng
On Wed, Jun 12, 2019 at 11:13:10AM +0200, Andrzej Hajda wrote:
> On 04.06.2019 14:23, Torsten Duwe wrote:
> > +
> > +static void anx6345_poweron(struct anx6345 *anx6345)
> > +{
> > + int err;
> > +
> > + /* Ensure reset is asserted before starting power on sequence */
> > + gpiod_set_value_cansleep(anx6345->gpiod_reset, 1);
>
> With fixed devm_gpiod_get below this line can be removed.
In any case, reset must be asserted for this procedure to succeed...
> > +static enum drm_mode_status
> > +anx6345_bridge_mode_valid(struct drm_bridge *bridge,
> > + const struct drm_display_mode *mode)
> > +{
> > + if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > + return MODE_NO_INTERLACE;
> > +
> > + /* Max 1200p at 5.4 Ghz, one lane */
> > + if (mode->clock > 154000)
> > + return MODE_CLOCK_HIGH;
>
> I wonder if you shouldn't take into account training results here, ie.
> training perfrormed before validation.
Sure, but this is verbatim from the anx78xx.c sibling, code provided
by analogix. Lacking in-depth datasheets, this is probably the best effort.
> > +
> > + /* 2.5V digital core power regulator */
> > + anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
> > + if (IS_ERR(anx6345->dvdd25)) {
> > + DRM_ERROR("dvdd25-supply not found\n");
> > + return PTR_ERR(anx6345->dvdd25);
> > + }
> > +
> > + /* GPIO for chip reset */
> > + anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
>
> Shouldn't be set to GPIOD_OUT_HIGH?
It used to be in the original submission, and confused even more people ;-)
Fact is, the reset for this chip _is_ low active; I'm following
Documentation/devicetree/bindings/gpio/gpio.txt, "1.1) GPIO specifier
best practices", which I find rather comprehensive.
Any suggestions on how to phrase this even better are appreciated.
> > +};
> > +module_i2c_driver(anx6345_driver);
> > +
> > +MODULE_DESCRIPTION("ANX6345 eDP Transmitter driver");
> > +MODULE_AUTHOR("Enric Balletbo i Serra <enric.balletbo@collabora.com>");
>
> Submitter, patch author, and module author are different, this can be
> correct, but maybe somebody forgot to update some of these fields.
As mentioned in the v2 cover letter, I had a closer look on which code got
actually introduced and which lines were simply copied around, and made the
copyright and authorship stick to where they belong. *I* believe this is
correct now; specific improvements welcome.
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] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
2019-07-16 0:28 ` Vasily Khoruzhick
@ 2019-07-24 13:58 ` Maxime Ripard
-1 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-24 13:58 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Andrzej Hajda, Torsten Duwe, Harald Geyer, Chen-Yu Tsai,
Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Daniel Vetter, Laurent Pinchart, Icenowy Zheng, Sean Paul,
Greg Kroah-Hartman, Thomas Gleixner, dri-devel, devicetree,
arm-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4866 bytes --]
On Mon, Jul 15, 2019 at 05:28:53PM -0700, Vasily Khoruzhick wrote:
> On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> > > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > > > same motherboard.
> > > > > >
> > > > > > And that's what that compatible is about :)
> > > > >
> > > > > Sorry, I fail to see how it would be different from using existing
> > > > > panels infrastructure and different panels compatibles. I think Rob's
> > > > > idea was to introduce generic edp-connector.
> > > >
> > > > Again, there's no such thing as a generic edp-connector. The spec
> > > > doesn't define anything related to the power sequence for example.
> > > >
> > > > > If we can't make it generic then let's use panel infrastructure.
> > > >
> > > > Which uses a device specific compatible. Really, I'm not sure what
> > > > your objection and / or argument is here.
> > > >
> > > > In addition, when that was brought up in the discussion, you rejected
> > > > it because it was inconvenient:
> > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
> > >
> > > It is inconvenient, but I don't understand how having board-specific
> > > connectors fixes it.
> >
> > How it would not fix it?
>
> I think I got your idea, but yet I think it's not the best solution.
>
> Do I understand correctly that you're proposing to introduce
> board-specific edp-connector driver that will be aware of worst case
> power up delays and will control backlight and power?
>
> Then why not to add another board-specific panel (e.g.
> "pine64,pinebook-panel") to simple-panel.c that does the same?
That would be fine for me too. Thierry was against it though IIRC, and
I don't recall why exactly.
> > You'll have one connector, without the need to describe each and every
> > panel in the device tree and rely on the EDID instead, and you'll have
> > the option to power up the regulator you need.
> >
> > I really don't understand what's the issue here, so let's take a step
> > back. What are is the issue , what are your requirements, and how
> > would you like that to be described ?
>
> We have a device (Pinebook) that uses the same board with multiple edp
> panels. So far there're pinebooks with 3 different panels: 11" with
> 768p panel, 11" with 1080p panel, 14" with 768p panel.
>
> Currently there's no way to describe all pinebooks with a single dts.
> There's a simple workaround though -- we can just specify a panel with
> worst power up delays in dts and it'll work since anx6345 driver
> ignores panel modes anyway and uses EDID.
>
> Originally I proposed to extend simple-panel driver to support generic
> edp-panel but it was rejected. I still believe that it's the best
> solution assuming we can specify delays in dts, since panels list is
> specific to particular device and it probably can't be reused, i.e.
> there's no good reason to move it into C code.
>
> Rob Herring proposed to introduce edp-connector. While I still believe
> that it's not accurate description of hardware since it'll have to
> have backlight node (backlight is actually panel property) I was OK
> with this approach assuming we can store delays in dts.
>
> Later it evolved into board-specific edp-connector.
I think you got that wrong. As far as I'm concerned, the plan was to
have two compatibles: the board-specific one, and the generic one.
Something like compatible = "pine64,pinebook-edp-connector",
"edp-connector"; or whatever.
> So far I don't understand why everyone is trying to avoid introducing
> edp-panel driver that can read delays from dts. Basically, I don't
> understand what's the magic behind simple-panel.c and why new panels
> should be added there rather than described in dts. [1] Doesn't
> explain that.
So others might have different viewpoints here as well, but the major
downside I see in putting those kind of values in the device tree is
that at some point, someone will get it wrong, and chances are that
even for the same panel, everyone will use a slightly different set of
timings.
And once it's wrong, then it's a mess to fix. You have to track down
every DT using it, make sure it's corrected, and then every user will
have to change their DT in their system. Whereas if you have just a
compatible and those timings in the kernel, then the only thing
required is a kernel update, which should be a pretty standard
operation.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I
@ 2019-07-24 13:58 ` Maxime Ripard
0 siblings, 0 replies; 90+ messages in thread
From: Maxime Ripard @ 2019-07-24 13:58 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Sean Paul, David Airlie,
Greg Kroah-Hartman, linux-kernel, dri-devel, Andrzej Hajda,
Chen-Yu Tsai, Rob Herring, Torsten Duwe, Laurent Pinchart,
Daniel Vetter, Harald Geyer, Thierry Reding, Thomas Gleixner,
arm-linux, Icenowy Zheng
[-- Attachment #1.1: Type: text/plain, Size: 4866 bytes --]
On Mon, Jul 15, 2019 at 05:28:53PM -0700, Vasily Khoruzhick wrote:
> On Fri, Jul 12, 2019 at 1:15 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Wed, Jul 10, 2019 at 03:11:04PM -0700, Vasily Khoruzhick wrote:
> > > On Wed, Jul 10, 2019 at 4:40 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > > There's another issue: if we introduce edp-connector we'll have to
> > > > > > > specify power up delays somewhere (in dts? or in platform driver?), so
> > > > > > > edp-connector doesn't really solve the issue of multiple panels with
> > > > > > > same motherboard.
> > > > > >
> > > > > > And that's what that compatible is about :)
> > > > >
> > > > > Sorry, I fail to see how it would be different from using existing
> > > > > panels infrastructure and different panels compatibles. I think Rob's
> > > > > idea was to introduce generic edp-connector.
> > > >
> > > > Again, there's no such thing as a generic edp-connector. The spec
> > > > doesn't define anything related to the power sequence for example.
> > > >
> > > > > If we can't make it generic then let's use panel infrastructure.
> > > >
> > > > Which uses a device specific compatible. Really, I'm not sure what
> > > > your objection and / or argument is here.
> > > >
> > > > In addition, when that was brought up in the discussion, you rejected
> > > > it because it was inconvenient:
> > > > https://patchwork.freedesktop.org/patch/283012/?series=56163&rev=1#comment_535206
> > >
> > > It is inconvenient, but I don't understand how having board-specific
> > > connectors fixes it.
> >
> > How it would not fix it?
>
> I think I got your idea, but yet I think it's not the best solution.
>
> Do I understand correctly that you're proposing to introduce
> board-specific edp-connector driver that will be aware of worst case
> power up delays and will control backlight and power?
>
> Then why not to add another board-specific panel (e.g.
> "pine64,pinebook-panel") to simple-panel.c that does the same?
That would be fine for me too. Thierry was against it though IIRC, and
I don't recall why exactly.
> > You'll have one connector, without the need to describe each and every
> > panel in the device tree and rely on the EDID instead, and you'll have
> > the option to power up the regulator you need.
> >
> > I really don't understand what's the issue here, so let's take a step
> > back. What are is the issue , what are your requirements, and how
> > would you like that to be described ?
>
> We have a device (Pinebook) that uses the same board with multiple edp
> panels. So far there're pinebooks with 3 different panels: 11" with
> 768p panel, 11" with 1080p panel, 14" with 768p panel.
>
> Currently there's no way to describe all pinebooks with a single dts.
> There's a simple workaround though -- we can just specify a panel with
> worst power up delays in dts and it'll work since anx6345 driver
> ignores panel modes anyway and uses EDID.
>
> Originally I proposed to extend simple-panel driver to support generic
> edp-panel but it was rejected. I still believe that it's the best
> solution assuming we can specify delays in dts, since panels list is
> specific to particular device and it probably can't be reused, i.e.
> there's no good reason to move it into C code.
>
> Rob Herring proposed to introduce edp-connector. While I still believe
> that it's not accurate description of hardware since it'll have to
> have backlight node (backlight is actually panel property) I was OK
> with this approach assuming we can store delays in dts.
>
> Later it evolved into board-specific edp-connector.
I think you got that wrong. As far as I'm concerned, the plan was to
have two compatibles: the board-specific one, and the generic one.
Something like compatible = "pine64,pinebook-edp-connector",
"edp-connector"; or whatever.
> So far I don't understand why everyone is trying to avoid introducing
> edp-panel driver that can read delays from dts. Basically, I don't
> understand what's the magic behind simple-panel.c and why new panels
> should be added there rather than described in dts. [1] Doesn't
> explain that.
So others might have different viewpoints here as well, but the major
downside I see in putting those kind of values in the device tree is
that at some point, someone will get it wrong, and chances are that
even for the same panel, everyone will use a slightly different set of
timings.
And once it's wrong, then it's a mess to fix. You have to track down
every DT using it, make sure it's corrected, and then every user will
have to change their DT in their system. Whereas if you have just a
compatible and those timings in the kernel, then the only thing
required is a kernel update, which should be a pretty standard
operation.
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] 90+ messages in thread
end of thread, other threads:[~2019-07-24 13:59 UTC | newest]
Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-04 12:21 [PATCH v2 0/7] Add anx6345 DP/eDP bridge for Olimex Teres-I Torsten Duwe
2019-06-04 12:21 ` Torsten Duwe
2019-06-04 12:22 ` [PATCH v2 1/7] drm/bridge: move ANA78xx driver to analogix subdirectory Torsten Duwe
2019-06-04 12:22 ` Torsten Duwe
2019-06-12 10:16 ` Andrzej Hajda
2019-06-12 10:16 ` Andrzej Hajda
2019-06-04 12:22 ` [PATCH v2 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers Torsten Duwe
2019-06-04 12:22 ` Torsten Duwe
2019-06-12 7:40 ` Andrzej Hajda
2019-06-12 7:40 ` Andrzej Hajda
2019-06-12 7:40 ` Andrzej Hajda
2019-06-04 12:22 ` [PATCH v2 3/7] drm/bridge: extract some Analogix I2C DP common code Torsten Duwe
2019-06-04 12:22 ` Torsten Duwe
2019-06-12 7:41 ` Andrzej Hajda
2019-06-12 7:41 ` Andrzej Hajda
2019-06-04 12:22 ` [PATCH v2 4/7] drm/bridge: Prepare Analogix anx6345 support Torsten Duwe
2019-06-04 12:22 ` Torsten Duwe
2019-06-12 7:43 ` Andrzej Hajda
2019-06-12 7:43 ` Andrzej Hajda
2019-06-04 12:23 ` [PATCH v2 5/7] drm/bridge: Add " Torsten Duwe
2019-06-04 12:23 ` Torsten Duwe
2019-06-12 9:13 ` Andrzej Hajda
2019-06-12 9:13 ` Andrzej Hajda
2019-07-18 16:42 ` Torsten Duwe
2019-07-18 16:42 ` Torsten Duwe
2019-06-04 12:23 ` [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding Torsten Duwe
2019-06-04 12:23 ` Torsten Duwe
2019-06-12 8:16 ` Andrzej Hajda
2019-06-12 8:16 ` Andrzej Hajda
2019-06-12 14:59 ` Torsten Duwe
2019-06-12 14:59 ` Torsten Duwe
2019-06-04 12:23 ` [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I Torsten Duwe
2019-06-04 12:23 ` Torsten Duwe
2019-06-04 15:08 ` Vasily Khoruzhick
2019-06-04 15:08 ` Vasily Khoruzhick
2019-06-04 15:08 ` Vasily Khoruzhick
2019-06-05 10:13 ` Torsten Duwe
2019-06-05 10:13 ` Torsten Duwe
2019-06-05 12:02 ` Maxime Ripard
2019-06-05 12:02 ` Maxime Ripard
2019-06-06 13:59 ` Harald Geyer
2019-06-06 13:59 ` Harald Geyer
2019-06-06 13:59 ` Harald Geyer
2019-06-07 6:28 ` Maxime Ripard
2019-06-07 6:28 ` Maxime Ripard
2019-06-07 6:28 ` Maxime Ripard
2019-06-07 9:40 ` Torsten Duwe
2019-06-07 9:40 ` Torsten Duwe
2019-06-12 10:00 ` Andrzej Hajda
2019-06-12 10:00 ` Andrzej Hajda
2019-06-12 10:00 ` Andrzej Hajda
2019-06-12 15:20 ` Maxime Ripard
2019-06-12 15:20 ` Maxime Ripard
2019-06-12 15:20 ` Maxime Ripard
2019-06-28 10:39 ` Andrzej Hajda
2019-06-28 10:39 ` Andrzej Hajda
2019-07-01 9:58 ` Maxime Ripard
2019-07-01 9:58 ` Maxime Ripard
2019-07-01 12:27 ` Andrzej Hajda
2019-07-01 12:27 ` Andrzej Hajda
2019-07-02 8:13 ` Maxime Ripard
2019-07-02 8:13 ` Maxime Ripard
2019-07-09 0:49 ` Vasily Khoruzhick
2019-07-09 0:49 ` Vasily Khoruzhick
2019-07-09 0:49 ` Vasily Khoruzhick
2019-07-09 8:55 ` Maxime Ripard
2019-07-09 8:55 ` Maxime Ripard
2019-07-09 8:55 ` Maxime Ripard
2019-07-09 8:58 ` Icenowy Zheng
2019-07-09 8:58 ` Icenowy Zheng
2019-07-09 8:58 ` Icenowy Zheng
2019-07-09 14:21 ` Maxime Ripard
2019-07-09 14:21 ` Maxime Ripard
2019-07-09 20:30 ` Vasily Khoruzhick
2019-07-09 20:30 ` Vasily Khoruzhick
2019-07-09 20:30 ` Vasily Khoruzhick
2019-07-10 11:40 ` Maxime Ripard
2019-07-10 11:40 ` Maxime Ripard
2019-07-10 22:11 ` Vasily Khoruzhick
2019-07-10 22:11 ` Vasily Khoruzhick
2019-07-12 20:15 ` Maxime Ripard
2019-07-12 20:15 ` Maxime Ripard
2019-07-16 0:28 ` Vasily Khoruzhick
2019-07-16 0:28 ` Vasily Khoruzhick
2019-07-16 0:28 ` Vasily Khoruzhick
2019-07-24 13:58 ` Maxime Ripard
2019-07-24 13:58 ` Maxime Ripard
2019-06-12 15:34 ` Maxime Ripard
2019-06-12 15:34 ` Maxime Ripard
2019-06-12 15:34 ` Maxime Ripard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.