RE: [PATCH v6] drm/bridge: add it6505 driver

2021-01-28 Thread allen.chen
Hi Andrzej

I will fixed these and upstream.

Thanks for your comment.


-Original Message-
From: Andrzej Hajda [mailto:a.ha...@samsung.com] 
Sent: Friday, January 22, 2021 7:02 PM
To: Allen Chen (陳柏宇)
Cc: Kenneth Hung (洪家倫); Jitao Shi; Jau-Chih Tseng (曾昭智); Yilun Lin; David 
Airlie; Neil Armstrong; Jernej Skrabec; open list:DRM DRIVERS; open list; 
Hermes Wu (吳佳宏); moderated list:ARM/Mediatek SoC support; Laurent Pinchart; 
Pi-Hsun Shih; Matthias Brugger; moderated list:ARM/Mediatek SoC support; Jonas 
Karlman
Subject: Re: [PATCH v6] drm/bridge: add it6505 driver

Hi Allen,

Sorry for long delay.

W dniu 08.12.2020 o 11:58, allen pisze:
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
>
> From: Allen Chen 
> Signed-off-by: Jitao Shi 
> Signed-off-by: Pi-Hsun Shih 
> Signed-off-by: Yilun Lin 
> Signed-off-by: Hermes Wu 
> Signed-off-by: Allen Chen 
> ---
>   drivers/gpu/drm/bridge/Kconfig  |7 +
>   drivers/gpu/drm/bridge/Makefile |1 +
>   drivers/gpu/drm/bridge/ite-it6505.c | 3343 +++
>   3 files changed, 3351 insertions(+)
>   create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e4110d6ca7b3c..25d34d7196004 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -74,6 +74,13 @@ config DRM_LONTIUM_LT9611UXC
> HDMI signals
> Please say Y if you have such hardware.
>   
> +config DRM_ITE_IT6505
> + tristate "ITE IT6505 DisplayPort bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + help
> +   ITE IT6505 DisplayPort bridge chip driver.
> +
>   config DRM_LVDS_CODEC
>   tristate "Transparent LVDS encoders and decoders support"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 86e7acc76f8d6..2b2f8f0b5b0fa 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>   obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
>   obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
>   obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
> +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o


Please keep alphabetic order.


>   obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
>   obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v3-fw.o
>   obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
> b/drivers/gpu/drm/bridge/ite-it6505.c
> new file mode 100644
> index 0..5e76719a51a4a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -0,0 +1,3343 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define REG_IC_VER 0x04
> +
> +#define REG_RESET_CTRL 0x05
> +#define VIDEO_RESET BIT(0)
> +#define AUDIO_RESET BIT(1)
> +#define ALL_LOGIC_RESET BIT(2)
> +#define AUX_RESET BIT(3)
> +#define HDCP_RESET BIT(4)
> +
> +#define INT_STATUS_01 0x06
> +#define INT_MASK_01 0x09
> +#define INT_HPD_CHANGE BIT(0)
> +#define INT_RECEIVE_HPD_IRQ BIT(1)
> +#define INT_SCDT_CHANGE BIT(2)
> +#define INT_HDCP_FAIL BIT(3)
> +#define INT_HDCP_DONE BIT(4)
> +
> +#define INT_STATUS_02 0x07
> +#define INT_MASK_02 0x0A
> +#define INT_AUX_CMD_FAIL BIT(0)
> +#define INT_HDCP_KSV_CHECK BIT(1)
> +#define INT_AUDIO_FIFO_ERROR BIT(2)
> +
> +#define INT_STATUS_03 0x08
> +#define INT_MASK_03 0x0B
> +#define INT_LINK_TRAIN_FAIL BIT(4)
> +#define INT_VID_FIFO_ERROR BIT(5)
> +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7)
> +
> +#define REG_SYSTEM_STS 0x0D
> +#define INT_STS BIT(0)
> +#define HPD_STS BIT(1)
> +#define VIDEO_STB BIT(2)
> +
> +#define REG_LINK_TRAIN_STS 0x0E
> +#define LINK_STATE_CR BIT(2)
> +#define LINK_STATE_EQ BIT(3)
> +#define LINK_STATE_NORP BIT(4)
> +
> +#define REG_BANK_SEL 0x0F
> +#define REG_CLK_CTRL0 0x10
> +#define M_PCLK_DELAY 0x03
> +
> +#define REG_AUX_OPT 0x11
> +#define AUX_AUTO_RST BIT(0)
> +#define AUX_FIX_FREQ BIT(3)
> +
> +#define REG_DATA_CTRL0 0x12
> +#define VIDEO_LATCH_EDGE BIT(4)
> +#define ENABLE_PCLK_COUNTER BIT(7)
> +
> +#define REG_PCLK_COUNTER_VALUE 0x13
> +
> +#define REG_501_FIFO_CTRL 0x15
> +#define RST_501_FIFO BIT(1)
> +
> +#define REG_TRAIN_CTRL0 0x16
> +#define FORCE_LBR BIT(0)
> +#define LANE_COUNT_MASK 0x06
> +#define LANE_SWAP BIT(3)
> +#define SPREAD_AMP_5 BIT(4)
> +#define FORCE_CR_DONE BIT(5)
> +#define FORCE_EQ_DONE BIT(6)
> +
> +#defi

RE: [PATCH v8] drm/bridge: add it6505 driver

2021-10-05 Thread allen.chen
Hi

It has been about two months since I posted v8
Consider this a gentle ping.

Just wondering if the set needs additional work and I will fix and upstream 
again.

-Original Message-
From: Allen Chen (陳柏宇) 
Sent: Tuesday, August 10, 2021 7:11 PM
Cc: Allen Chen (陳柏宇); Hsin-Yi Wang; Kenneth Hung (洪家倫); Hermes Wu (吳佳宏); 
Jau-Chih Tseng (曾昭智); Hsin-yi Wang; Hermes Wu (吳佳宏); Andrzej Hajda; Neil 
Armstrong; Robert Foss; Laurent Pinchart; Jonas Karlman; Jernej Skrabec; David 
Airlie; Daniel Vetter; Matthias Brugger; open list; open list:DRM DRIVERS; 
moderated list:ARM/Mediatek SoC support; moderated list:ARM/Mediatek SoC support
Subject: [PATCH v8] drm/bridge: add it6505 driver

This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.

From: Allen Chen 
Tested-by: Hsin-yi Wang 
Signed-off-by: Hermes Wu 
Signed-off-by: Allen Chen 

v7->v8:
fixed "checkpatch --strict" error
remove unused variable *edid
remove mode_set() callback
Documenting the individual bits of the interrupt mask values
change it6505_dpcd_write parameter from unsigned long to u8

This patch depends on 
https://patchwork.kernel.org/project/linux-mediatek/patch/20210722062246.2512666-4-...@ravnborg.org/
---
 drivers/gpu/drm/bridge/Kconfig  |8 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ite-it6505.c |  +++
 3 files changed, 3342 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 431b6e12a81fe..e1afe171075f5 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -74,6 +74,14 @@ config DRM_DISPLAY_CONNECTOR
  on ARM-based platforms. Saying Y here when this driver is not needed
  will not cause any issue.
 
+config DRM_ITE_IT6505
+tristate "ITE IT6505 DisplayPort bridge"
+depends on OF
+select DRM_KMS_HELPER
+select EXTCON
+help
+  ITE IT6505 DisplayPort bridge chip driver.
+
 config DRM_LONTIUM_LT8912B
tristate "Lontium LT8912B DSI/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f2c73683cfcb7..425844c304953 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHIPONE_ICN6211) += chipone-icn6211.o
 obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
 obj-$(CONFIG_DRM_CROS_EC_ANX7688) += cros-ec-anx7688.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_LONTIUM_LT8912B) += lontium-lt8912b.o
 obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
 obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index 0..27586c3fd5f28
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1, @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define REG_IC_VER 0x04
+
+#define REG_RESET_CTRL 0x05
+#define VIDEO_RESET BIT(0)
+#define AUDIO_RESET BIT(1)
+#define ALL_LOGIC_RESET BIT(2)
+#define AUX_RESET BIT(3)
+#define HDCP_RESET BIT(4)
+
+#define INT_STATUS_01 0x06
+#define INT_MASK_01 0x09
+#define INT_HPD_CHANGE 0
+#define INT_RECEIVE_HPD_IRQ 1
+#define INT_SCDT_CHANGE 2
+#define INT_HDCP_FAIL 3
+#define INT_HDCP_DONE 4
+#define BIT_OFFSET(x) (((x) - INT_STATUS_01) * BITS_PER_BYTE)
+#define BIT_INT_HPD INT_HPD_CHANGE
+#define BIT_INT_HPD_IRQ INT_RECEIVE_HPD_IRQ
+#define BIT_INT_SCDT INT_SCDT_CHANGE
+#define BIT_INT_HDCP_FAIL INT_HDCP_FAIL
+#define BIT_INT_HDCP_DONE INT_HDCP_DONE
+
+#define INT_STATUS_02 0x07
+#define INT_MASK_02 0x0A
+#define INT_AUX_CMD_FAIL 0
+#define INT_HDCP_KSV_CHECK 1
+#define INT_AUDIO_FIFO_ERROR 2
+#define BIT_INT_AUX_CMD_FAIL (BIT_OFFSET(0x07) + INT_AUX_CMD_FAIL)
+#define BIT_INT_HDCP_KSV_CHECK (BIT_OFFSET(0x07) + INT_HDCP_KSV_CHECK)
+#define BIT_INT_AUDIO_FIFO_ERROR (BIT_OFFSET(0x07) + INT_AUDIO_FIFO_ERROR)
+
+#define INT_STATUS_03 0x08
+#define INT_MASK_03 0x0B
+#define INT_LINK_TRAIN_FAIL 4
+#define INT_VID_FIFO_ERROR 5
+#define INT_IO_LATCH_FIFO_OVERFLOW 7
+#define BIT_INT_LINK_TRAIN_FAIL (BIT_OFFSET(0x08) + INT_LINK_TRAIN_FAIL)
+#define BIT_INT_VID_FIFO_ERROR (BIT_OFFSET(0x08) + INT_VID_FIFO_ERROR)
+#define BIT_INT_IO_FIFO_OVERFLOW (BIT_OFFSET(0x08) + 
INT_IO_LATCH_FIFO_OVERFLOW)
+
+#define REG_SYSTEM_STS 0x0D
+#define INT_STS BIT(0)
+#define HPD_STS BIT(1)
+#define VIDEO_STB BIT(2)
+
+#define REG_LINK

RE: [PATCH v6] drm/bridge: add it6505 driver

2020-12-18 Thread allen.chen
Hi Mathieu

For google reference design(mt8183+it6505), the maximum 95000kHz is depends on 
mt8183 requirement.

-Original Message-
From: Mathieu Tournier [mailto:mathieutourn...@gmail.com] 
Sent: Thursday, December 17, 2020 2:47 AM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Kenneth Hung (洪家倫); 
laurent.pinch...@ideasonboard.com; a.ha...@samsung.com; airl...@linux.ie; 
dri-devel@lists.freedesktop.org; Hermes Wu (吳佳宏); jernej.skra...@siol.net; 
jitao@mediatek.com; jo...@kwiboo.se; linux-arm-ker...@lists.infradead.org; 
linux-ker...@vger.kernel.org; linux-media...@lists.infradead.org; 
matthias@gmail.com; narmstr...@baylibre.com; pih...@chromium.org; 
yl...@google.com
Subject: Re: [PATCH v6] drm/bridge: add it6505 driver

Hi Allen.

As it6505 is compatible with DisplayPort 1.1a,
Should DPI_PIXEL_CLK_MAX be 165 000 instead of 95 000 khz ?
This would permit 1080p support, as it may be supported.

Mathieu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH v6] drm/bridge: add it6505 driver

2020-12-23 Thread allen.chen
Hi

It has been about two weeks since I posted v6 and haven't heard anything.
Consider this a gentle ping.

Just wondering if the set needs additional work and I will fix and upstream 
again.

Thanks.

-Original Message-
From: Allen Chen (陳柏宇) 
Sent: Tuesday, December 08, 2020 6:58 PM
Cc: Jau-Chih Tseng (曾昭智); Hermes Wu (吳佳宏); Kenneth Hung (洪家倫); Allen Chen 
(陳柏宇); Pi-Hsun Shih; Jitao Shi; Yilun Lin; Hermes Wu (吳佳宏); Andrzej Hajda; Neil 
Armstrong; Laurent Pinchart; Jonas Karlman; Jernej Skrabec; David Airlie; 
Daniel Vetter; Matthias Brugger; open list; open list:DRM DRIVERS; moderated 
list:ARM/Mediatek SoC support; moderated list:ARM/Mediatek SoC support
Subject: [PATCH v6] drm/bridge: add it6505 driver

This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.

From: Allen Chen 
Signed-off-by: Jitao Shi 
Signed-off-by: Pi-Hsun Shih 
Signed-off-by: Yilun Lin 
Signed-off-by: Hermes Wu 
Signed-off-by: Allen Chen 
---
 drivers/gpu/drm/bridge/Kconfig  |7 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ite-it6505.c | 3343 +++
 3 files changed, 3351 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3c..25d34d7196004 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -74,6 +74,13 @@ config DRM_LONTIUM_LT9611UXC
  HDMI signals
  Please say Y if you have such hardware.
 
+config DRM_ITE_IT6505
+   tristate "ITE IT6505 DisplayPort bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ ITE IT6505 DisplayPort bridge chip driver.
+
 config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d6..2b2f8f0b5b0fa 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
 obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index 0..5e76719a51a4a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1,3343 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define REG_IC_VER 0x04
+
+#define REG_RESET_CTRL 0x05
+#define VIDEO_RESET BIT(0)
+#define AUDIO_RESET BIT(1)
+#define ALL_LOGIC_RESET BIT(2)
+#define AUX_RESET BIT(3)
+#define HDCP_RESET BIT(4)
+
+#define INT_STATUS_01 0x06
+#define INT_MASK_01 0x09
+#define INT_HPD_CHANGE BIT(0)
+#define INT_RECEIVE_HPD_IRQ BIT(1)
+#define INT_SCDT_CHANGE BIT(2)
+#define INT_HDCP_FAIL BIT(3)
+#define INT_HDCP_DONE BIT(4)
+
+#define INT_STATUS_02 0x07
+#define INT_MASK_02 0x0A
+#define INT_AUX_CMD_FAIL BIT(0)
+#define INT_HDCP_KSV_CHECK BIT(1)
+#define INT_AUDIO_FIFO_ERROR BIT(2)
+
+#define INT_STATUS_03 0x08
+#define INT_MASK_03 0x0B
+#define INT_LINK_TRAIN_FAIL BIT(4)
+#define INT_VID_FIFO_ERROR BIT(5)
+#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7)
+
+#define REG_SYSTEM_STS 0x0D
+#define INT_STS BIT(0)
+#define HPD_STS BIT(1)
+#define VIDEO_STB BIT(2)
+
+#define REG_LINK_TRAIN_STS 0x0E
+#define LINK_STATE_CR BIT(2)
+#define LINK_STATE_EQ BIT(3)
+#define LINK_STATE_NORP BIT(4)
+
+#define REG_BANK_SEL 0x0F
+#define REG_CLK_CTRL0 0x10
+#define M_PCLK_DELAY 0x03
+
+#define REG_AUX_OPT 0x11
+#define AUX_AUTO_RST BIT(0)
+#define AUX_FIX_FREQ BIT(3)
+
+#define REG_DATA_CTRL0 0x12
+#define VIDEO_LATCH_EDGE BIT(4)
+#define ENABLE_PCLK_COUNTER BIT(7)
+
+#define REG_PCLK_COUNTER_VALUE 0x13
+
+#define REG_501_FIFO_CTRL 0x15
+#define RST_501_FIFO BIT(1)
+
+#define REG_TRAIN_CTRL0 0x16
+#define FORCE_LBR BIT(0)
+#define LANE_COUNT_MASK 0x06
+#define LANE_SWAP BIT(3)
+#define SPREAD_AMP_5 BIT(4)
+#define FORCE_CR_DONE BIT(5)
+#define FORCE_EQ_DONE BIT(6)
+
+#define REG_TRAIN_CTRL1 0x17
+#define AUTO_TRAIN BIT(0)
+#define MANUAL_TRAIN BIT(1)
+#define FORCE_RETRAIN BIT(2)
+
+#define REG_AUX_CTRL 0x23
+#define CLR_EDID_FIFO BIT(0)
+#define AUX_USER_MODE BIT(1)
+#define AUX_NO_SEGMENT_WR BIT(6)
+#define AUX_EN_FIFO_READ BIT(7

RE: [PATCH v6] drm/bridge: add it6505 driver

2020-12-23 Thread allen.chen
Hi Laurent Pinchart

Thanks for reply.

-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] 
Sent: Wednesday, December 23, 2020 12:20 AM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Hermes Wu (吳佳宏); Kenneth Hung (洪家倫); 
pih...@chromium.org; jitao@mediatek.com; yl...@google.com; 
a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se; 
jernej.skra...@siol.net; airl...@linux.ie; dan...@ffwll.ch; 
matthias@gmail.com; linux-ker...@vger.kernel.org; 
dri-devel@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org; 
linux-media...@lists.infradead.org
Subject: Re: [PATCH v6] drm/bridge: add it6505 driver

Hi Allen,

On Tue, Dec 22, 2020 at 11:29:34AM +, allen.c...@ite.com.tw wrote:
> Hi
> 
> It has been about two weeks since I posted v6 and haven't heard anything.
> Consider this a gentle ping.
> 
> Just wondering if the set needs additional work and I will fix and
> upstream again.

I'm afraid I don't have enough bandwidth these days to review all new
bridge drivers :-S Maybe one of the DRM bridge maintainers would have
more time to spend ?

> -Original Message-
> From: Allen Chen (陳柏宇) 
> Sent: Tuesday, December 08, 2020 6:58 PM
> Cc: Jau-Chih Tseng (曾昭智); Hermes Wu (吳佳宏); Kenneth Hung (洪家倫); Allen Chen 
> (陳柏宇); Pi-Hsun Shih; Jitao Shi; Yilun Lin; Hermes Wu (吳佳宏); Andrzej Hajda; 
> Neil Armstrong; Laurent Pinchart; Jonas Karlman; Jernej Skrabec; David 
> Airlie; Daniel Vetter; Matthias Brugger; open list; open list:DRM DRIVERS; 
> moderated list:ARM/Mediatek SoC support; moderated list:ARM/Mediatek SoC 
> support
> Subject: [PATCH v6] drm/bridge: add it6505 driver
> 
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
> 
> From: Allen Chen 
> Signed-off-by: Jitao Shi 
> Signed-off-by: Pi-Hsun Shih 
> Signed-off-by: Yilun Lin 
> Signed-off-by: Hermes Wu 
> Signed-off-by: Allen Chen 
> ---
>  drivers/gpu/drm/bridge/Kconfig  |7 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/ite-it6505.c | 3343 +++
>  3 files changed, 3351 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index e4110d6ca7b3c..25d34d7196004 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -74,6 +74,13 @@ config DRM_LONTIUM_LT9611UXC
> HDMI signals
> Please say Y if you have such hardware.
>  
> +config DRM_ITE_IT6505
> + tristate "ITE IT6505 DisplayPort bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + help
> +   ITE IT6505 DisplayPort bridge chip driver.
> +
>  config DRM_LVDS_CODEC
>   tristate "Transparent LVDS encoders and decoders support"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 86e7acc76f8d6..2b2f8f0b5b0fa 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>  obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
>  obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
>  obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
> +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
>  obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
>  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v3-fw.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
> b/drivers/gpu/drm/bridge/ite-it6505.c
> new file mode 100644
> index 0..5e76719a51a4a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -0,0 +1,3343 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define REG_IC_VER 0x04
> +
> +#define REG_RESET_CTRL 0x05
> +#define VIDEO_RESET BIT(0)
> +#define AUDIO_RESET BIT(1)
> +#define ALL_LOGIC_RESET BIT(2)
> +#define AUX_RESET BIT(3)
> +#define HDCP_RESET BIT(4)
> +
> +#define INT_STATUS_01 0x06
> +#define INT_MASK_01 0x09
> +#define INT_HPD_CHANGE BIT(0)
> +#define INT_RECEIVE_HPD_IRQ BIT(1)
> +#define INT_SCDT_CHANGE BIT(2)
> +#define INT_HDCP_FAIL BIT(3)
> +#define INT_HDCP_DONE BIT(4)
> +
> +#define INT_STATUS_02 0x07
> +#define INT_MASK_02 0x0A
> +#define INT_AUX_CMD_FAIL BIT(0)
> +#define INT_HDCP_KSV_CHECK BIT(1)
> +#define INT_AUDIO_FIFO_ERROR BIT(2)
> +
> +#define INT_STATUS_03 0x08
> +#define INT_MASK_03 0x0B
> +#define INT_LINK_TRAIN_FAIL BIT(4)
> +#d

RE: [PATCH] drm/bridge: add it6505 driver read config from dt property

2022-07-12 Thread allen.chen
Hi AngeloGioacchino

According to video-interfaces.yaml, property data-lanes should in the endpoint. 
It6505 has dpi input and no data-lanes parameters. It6505 has dp output and has 
data-lanes parameters. We want to use data-lanes in the output, but output 
point use extcon instead of endpoint. Do not have output endpoint.
Which line in dts should data-lanes be in?
Below is it6505 dts 

Thanks for your suggestion!

dp-bridge@5c {
compatible = "ite,it6505";
interrupts = <152 IRQ_TYPE_EDGE_FALLING 152 0>;
reg = <0x5c>;
pinctrl-names = "default";
pinctrl-0 = <&it6505_pins>;
ovdd-supply = <&mt6358_vsim1_reg>;
pwr18-supply = <&it6505_pp18_reg>;
reset-gpios = <&pio 179 1>;
extcon = <&usbc_extcon>;

port {
it6505_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
};


-Original Message-
From: AngeloGioacchino Del Regno  
Sent: Monday, June 27, 2022 8:55 PM
To: Allen Chen (陳柏宇) 
Cc: Pin-yen Lin ; Jau-Chih Tseng (曾昭智) 
; Hermes Wu (吳佳宏) ; Kenneth 
Hung (洪家倫) ; Allen-kh Cheng 
; Pin-yen Lin 
; Andrzej Hajda ; Neil 
Armstrong ; Robert Foss ; 
Laurent Pinchart ; Jonas Karlman 
; Jernej Skrabec ; David Airlie 
; Daniel Vetter ; Matthias Brugger 
; open list:DRM DRIVERS 
; open list ; 
moderated list:ARM/Mediatek SoC support ; 
moderated list:ARM/Mediatek SoC support 
Subject: Re: [PATCH] drm/bridge: add it6505 driver read config from dt property

Il 23/06/22 11:31, allen ha scritto:
> From: allen chen 
> 
> add read max-lane and max-pixel-clock from dt property
> 
> Signed-off-by: Allen-kh Cheng 
> 
> Signed-off-by: Pin-yen Lin 

Hello Allen,

as Sam also pointed out, please fix your S-o-b email: it has to match with the 
author one.

Anyway, you're adding devicetree properties, so this implies that you should 
also change the dt-bindings documentation for this driver... and also, I have 
some more comments, check below:

> ---
>   drivers/gpu/drm/bridge/ite-it6505.c | 35 ++---
>   1 file changed, 32 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
> b/drivers/gpu/drm/bridge/ite-it6505.c
> index 4b673c4792d77..c9121d4635a52 100644
> --- a/drivers/gpu/drm/bridge/ite-it6505.c
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -436,6 +436,8 @@ struct it6505 {
>   bool powered;
>   bool hpd_state;
>   u32 afe_setting;
> + u32 max_dpi_pixel_clock;
> + u32 max_lane_count;
>   enum hdcp_state hdcp_status;
>   struct delayed_work hdcp_work;
>   struct work_struct hdcp_wait_ksv_list; @@ -1466,7 +1468,8 @@ static 
> void it6505_parse_link_capabilities(struct it6505 *it6505)
>   it6505->lane_count = link->num_lanes;
>   DRM_DEV_DEBUG_DRIVER(dev, "Sink support %d lanes training",
>it6505->lane_count);
> - it6505->lane_count = min_t(int, it6505->lane_count, MAX_LANE_COUNT);
> + it6505->lane_count = min_t(int, it6505->lane_count,
> +it6505->max_lane_count);
>   
>   it6505->branch_device = drm_dp_is_branch(it6505->dpcd);
>   DRM_DEV_DEBUG_DRIVER(dev, "Sink %sbranch device", @@ -2895,7 
> +2898,7 @@ it6505_bridge_mode_valid(struct drm_bridge *bridge,
>   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
>   return MODE_NO_INTERLACE;
>   
> - if (mode->clock > DPI_PIXEL_CLK_MAX)
> + if (mode->clock > it6505->max_dpi_pixel_clock)
>   return MODE_CLOCK_HIGH;
>   
>   it6505->video_info.clock = mode->clock; @@ -3057,6 +3060,8 @@ 
> static void it6505_parse_dt(struct it6505 *it6505)
>   {
>   struct device *dev = &it6505->client->dev;
>   u32 *afe_setting = &it6505->afe_setting;
> + u32 *max_lane_count = &it6505->max_lane_count;
> + u32 *max_dpi_pixel_clock = &it6505->max_dpi_pixel_clock;
>   
>   it6505->lane_swap_disabled =
>   device_property_read_bool(dev, "no-laneswap"); @@ -3072,7 
> +3077,31 
> @@ static void it6505_parse_dt(struct it6505 *it6505)
>   } else {
>   *afe_setting = 0;
>   }
> - DRM_DEV_DEBUG_DRIVER(dev, "using afe_setting: %d", *afe_setting);
> +
> + if (device_property_read_u32(dev, "max-lane-count",

Please use the standard property "data-lanes" from video-interfaces.yaml.

> +  max_lane_count) == 0) {
> + if (*max_lane_count > 4 || *max_lane_count == 3) {
> + dev_err(dev, "max lane count error, use default");
> + *max_lane_count = MAX_LANE_COUNT;
> + }
> + } else {
> + *max_lane_count = MAX_LANE_COUNT;
> + }
> +
> + if (device_property_read_u32(dev, "max-dpi-pixel-clock",
> +  max_dpi_pixel_clock) == 0) {

What about "max-pixel-clock-khz" or "max-pixel-clock-hz"?


Regards,
Angelo


RE: [PATCH v2] drm/bridge: it6505: Power on downstream device in .atomic_enable

2022-07-14 Thread allen.chen
Reviewed-by: Allen Chen 

-Original Message-
From: Pin-Yen Lin  
Sent: Thursday, July 14, 2022 5:39 PM
To: Andrzej Hajda ; Neil Armstrong 
; Robert Foss ; Laurent 
Pinchart ; Jonas Karlman ; 
Jernej Skrabec ; David Airlie ; 
Daniel Vetter 
Cc: Hsin-Yi Wang ; Allen Chen (陳柏宇) 
; Pin-Yen Lin ; 
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: [PATCH v2] drm/bridge: it6505: Power on downstream device in 
.atomic_enable

Send DPCD DP_SET_POWER_D0 command to the monitor in .atomic_enable callback. 
Without this command, some monitors won't show up again after changing the 
resolution.

Fixes: 46ca7da7f1e8 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream")

Signed-off-by: Pin-Yen Lin 
---

Changes in v2:
- Update the typo in the summary (power on --> power off)
- Re-write the commit message to make it clearer.

 drivers/gpu/drm/bridge/ite-it6505.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index 4b673c4792d7..e5626035f311 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2945,6 +2945,9 @@ static void it6505_bridge_atomic_enable(struct drm_bridge 
*bridge,
if (ret)
dev_err(dev, "Failed to setup AVI infoframe: %d", ret);
 
+   it6505_drm_dp_link_set_power(&it6505->aux, &it6505->link,
+DP_SET_POWER_D0);
+
it6505_update_video_parameter(it6505, mode);
 
ret = it6505_send_video_infoframe(it6505, &frame);
--
2.37.0.144.g8ac04bfd2-goog



RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic

2019-11-10 Thread allen.chen
Hi Ville Syrjälä

Thanks for your suggestion and I have replied two comments below.

From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] 
Sent: Thursday, November 07, 2019 11:42 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; open list; open list:DRM DRIVERS; 
David Airlie; Pi-Hsun Shih; Sean Paul
Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
timings logic

On Mon, Nov 04, 2019 at 04:42:49PM +0800, allen wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First:  read detailed timing descriptor and make sure byte0 = 0,
>   byte1 = 0, byte2 = 0 and byte3 = 0xFD

That should probably be some new function:
bool is_display_descriptor(const u8 *desc, u8 tag);
is_display_descriptor(EDID_DETAIL_MONITOR_RANGE)
or something along those lines

We don't seem to check that in most places so should be rolled out all
over. The usage of struct detailed_timing all over also makes everything
rather confusing.

> Second: read detailed timing descriptor byte10 = 0x04 and
>   EDID byte18h bit0 = 1

Indicates CVT support. Should give these things real names so
one wouldn't have to decode by hand.

> Third:  if EDID byte18h bit0 == 1 && byte10 == 0x04,
>   then we can check byte15, if byte15 bit4 =1 is support RB
> if EDID byte18h bit0 != 1 || byte10 != 0x04,
>   then byte15 can not be used
> 
> The linux code is_rb function not follow the VESA's rule
> 
> EDID 1.3
> LCD flat panels do not require long blanking intervals as a retrace
> period so default support reduced-blanking timings.
> 
> Signed-off-by: Allen Chen 
> Reported-by: kbuild test robot 
> ---
>  drivers/gpu/drm/drm_edid.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e5e7e65..9b67b80 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -93,6 +93,11 @@ struct detailed_mode_closure {
>   int modes;
>  };
>  
> +struct edid_support_rb_closure {
> + struct edid *edid;
> + s8 support_rb;

bool

==> ITE:  If use bool, we could not return EDID1.3 when EDID1.4 logic can not 
be applied
> +};
> +
>  #define LEVEL_DMT0
>  #define LEVEL_GTF1
>  #define LEVEL_GTF2   2
> @@ -2018,22 +2023,31 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
> drm_device *dev,
>  is_rb(struct detailed_timing *t, void *data)
>  {
>   u8 *r = (u8 *)t;
> - if (r[3] == EDID_DETAIL_MONITOR_RANGE)
> - if (r[15] & 0x10)
> - *(bool *)data = true;
> + struct edid_support_rb_closure *closure = data;
> + struct edid *edid = closure->edid;
> +
> + if (!r[0] && !r[1] && !r[2] && r[3] == EDID_DETAIL_MONITOR_RANGE) {
> + if (edid->features & BIT(0) && r[10] == BIT(2))
> + closure->support_rb = (r[15] & 0x10) ? 1 : 0;

With the bool the ternary operator is not needed. Also should maybe 
be |= in case we have multiple range descriptors? Not sure that is
legal.

> + }
>  }
>  
>  /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */
>  static bool
>  drm_monitor_supports_rb(struct edid *edid)
>  {
> + struct edid_support_rb_closure closure = {
> + .edid = edid,
> + .support_rb = -1,
> + };
> +
>   if (edid->revision >= 4) {
> - bool ret = false;
> - drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
> - return ret;
> + drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);
> + if (closure.support_rb >= 0)
> + return closure.support_rb;
>   }
>  
> - return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);
> + return true;

Why are we now assuming rb for all pre 1.4 EDIDs?

==> ITE: Today, most of the monitor are LCD and LCD monitor do not require long 
blanking intervals as a retrace period so default support reduced-blanking 
timings.

>  }
>  
>  static void
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic

2019-12-11 Thread allen.chen
Hi Jani

Thanks for your help and I will follow your suggestion to modify the patch.

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
Sent: Tuesday, December 10, 2019 7:10 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; Allen Chen (陳柏宇); open list; open 
list:DRM DRIVERS; David Airlie; Pi-Hsun Shih; Sean Paul
Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
timings logic

On Tue, 26 Nov 2019, allen  wrote:
> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD
> (Defines EDID Structure Version 1, Revision 4) page: 39
> How to determine whether the monitor support RB timing or not?
> EDID 1.4
> First:  read detailed timing descriptor and make sure byte 0 = 0x00,
>   byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD
> Second: read EDID bit 0 in feature support byte at address 18h = 1
>   and detailed timing descriptor byte 10 = 0x04
> Third:  if EDID bit 0 in feature support byte = 1 &&
>   detailed timing descriptor byte 10 = 0x04
>   then we can check byte 15, if bit 4 in byte 15 = 1 is support RB
> if EDID bit 0 in feature support byte != 1 ||
>   detailed timing descriptor byte 10 != 0x04,
>   then byte 15 can not be used
>
> The linux code is_rb function not follow the VESA's rule
>
> Signed-off-by: Allen Chen 
> Reported-by: kbuild test robot 
> ---
>  drivers/gpu/drm/drm_edid.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index f5926bf..e11e585 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -93,6 +93,12 @@ struct detailed_mode_closure {
>   int modes;
>  };
>  
> +struct edid_support_rb_closure {
> + struct edid *edid;
> + bool valid_support_rb;
> + bool support_rb;
> +};
> +
>  #define LEVEL_DMT0
>  #define LEVEL_GTF1
>  #define LEVEL_GTF2   2
> @@ -2017,23 +2023,41 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
> drm_device *dev,
>   }
>  }
>  
> +static bool
> +is_display_descriptor(const u8 *r, u8 tag)
> +{
> + return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;
> +}
> +
>  static void
>  is_rb(struct detailed_timing *t, void *data)
>  {
>   u8 *r = (u8 *)t;
> - if (r[3] == EDID_DETAIL_MONITOR_RANGE)
> - if (r[15] & 0x10)
> - *(bool *)data = true;
> + struct edid_support_rb_closure *closure = data;
> + struct edid *edid = closure->edid;
> +
> + if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {
> + if (edid->features & BIT(0) && r[10] == BIT(2)) {

I'll try to explain my original comment again.

Consider edid->features & BIT(0). It remains unchanged across the
iteration. The code will only change anything if edid->features &
BIT(0).

> + closure->valid_support_rb = true;
> + closure->support_rb = (r[15] & 0x10) ? true : false;

You could combine these to e.g. a single int.

if (r[10] == BIT(2)) {
int *ret = data;
*ret = !!(r[15] & 0x10);
}

> + }
> + }
>  }
>  
>  /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */
>  static bool
>  drm_monitor_supports_rb(struct edid *edid)
>  {
> + struct edid_support_rb_closure closure = {
> + .edid = edid,
> + .valid_support_rb = false,
> + .support_rb = false,
> + };
> +
>   if (edid->revision >= 4) {
> - bool ret = false;
> - drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
> - return ret;
> + drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);
> + if (closure.valid_support_rb)
> + return closure.support_rb;

Here, you'd do:

if (edid->features & BIT(0)) {
int ret = -1;
drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);
if (ret != -1)
return ret;
}


>   }
>  
>   return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic

2019-12-03 Thread allen.chen
Hi Jani Nikula



Thanks for your suggestion and I have replied two comments below.



-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Wednesday, November 27, 2019 6:29 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; Allen Chen (陳柏宇); open list; open 
list:DRM DRIVERS; David Airlie; Pi-Hsun Shih; Sean Paul
Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
timings logic



On Tue, 26 Nov 2019, allen  wrote:

> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD

> (Defines EDID Structure Version 1, Revision 4) page: 39

> How to determine whether the monitor support RB timing or not?

> EDID 1.4

> First:  read detailed timing descriptor and make sure byte 0 = 0x00,

> byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD

> Second: read EDID bit 0 in feature support byte at address 18h = 1

> and detailed timing descriptor byte 10 = 0x04

> Third:  if EDID bit 0 in feature support byte = 1 &&

> detailed timing descriptor byte 10 = 0x04

> then we can check byte 15, if bit 4 in byte 15 = 1 is support RB

> if EDID bit 0 in feature support byte != 1 ||

> detailed timing descriptor byte 10 != 0x04,

> then byte 15 can not be used

>

> The linux code is_rb function not follow the VESA's rule

>

> Signed-off-by: Allen Chen 

> Reported-by: kbuild test robot 

> ---

>  drivers/gpu/drm/drm_edid.c | 36 ++--

>  1 file changed, 30 insertions(+), 6 deletions(-)

>

> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c

> index f5926bf..e11e585 100644

> --- a/drivers/gpu/drm/drm_edid.c

> +++ b/drivers/gpu/drm/drm_edid.c

> @@ -93,6 +93,12 @@ struct detailed_mode_closure {

>int modes;

>  };

>

> +struct edid_support_rb_closure {

> +   struct edid *edid;

> +   bool valid_support_rb;

> +   bool support_rb;

> +};

> +

>  #define LEVEL_DMT 0

>  #define LEVEL_GTF   1

>  #define LEVEL_GTF2 2

> @@ -2017,23 +2023,41 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
> drm_device *dev,

>}

>  }

>

> +static bool

> +is_display_descriptor(const u8 *r, u8 tag)

> +{

> +   return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;

> +}

> +

>  static void

>  is_rb(struct detailed_timing *t, void *data)

>  {

>u8 *r = (u8 *)t;

> -if (r[3] == EDID_DETAIL_MONITOR_RANGE)

> -if (r[15] & 0x10)

> -*(bool *)data = true;

> +   struct edid_support_rb_closure *closure = data;

> +   struct edid *edid = closure->edid;

> +

> +   if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {

> +   if (edid->features & BIT(0) && r[10] == BIT(2)) {

> +   closure->valid_support_rb = true;

> +   closure->support_rb = (r[15] & 0x10) ? true : false;

> +   }

> +   }

>  }

>

>  /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */

>  static bool

>  drm_monitor_supports_rb(struct edid *edid)

>  {

> +   struct edid_support_rb_closure closure = {

> +   .edid = edid,

> +   .valid_support_rb = false,

> +   .support_rb = false,

> +   };

> +

>if (edid->revision >= 4) {

> -bool ret = false;

> -drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);

> -return ret;

> +   drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);

> +   if (closure.valid_support_rb)

> +   return closure.support_rb;



Are you planning on extending the closure use somehow?



I did not look up the spec,



==> iTE: as the picture below, from VESA E-EDID standard

[cid:image003.jpg@01D5A9EA.9B7364D0]



[cid:image005.jpg@01D5A9EA.9B7364D0]



if EDID bit 0 in feature support byte = 1 && detailed timing descriptor byte 10 
= 0x04 then the CVT timing supported.



[cid:image009.jpg@01D5A9EA.9B7364D0]



If CVT timing supported then we can check byte 15 bit 4 to determine whether 
the reduced-blanking timings suported or not.

If CVT timing not supported then we can not use byte 15 to judge.

but purely on the code changes alone, you

could just move the edid->features bit check at this level, and not pass

it down, and nothing would change. I.e. don't iterate the EDID at all if

the bit is not set.



ð  iTE: We still have to check whether detailed timing descriptor byte 10 = 
0x04 or not, so it is hard to check at this level

You also don't actually use the distinction between valid_support_rb

vs. support_rb for anything, so the closure just adds code.



BR,

Jani.





>}

>

>return ((edid->input & DRM_EDID_INPUT_DIGITAL) != 0);



--

Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic

2019-12-04 Thread allen.chen
Hi Jani Nikula



Thanks for your suggestion and I have replied one comment below.



-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Tuesday, December 03, 2019 4:02 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); maxime.rip...@bootlin.com; 
linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; 
airl...@linux.ie; pih...@chromium.org; s...@poorly.run
Subject: RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
timings logic



On Tue, 03 Dec 2019,  wrote:

> Hi Jani Nikula

>

>

>

> Thanks for your suggestion and I have replied two comments below.



Please read my question again.



BR,

Jani.



>

>

>

> -Original Message-

> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]

> Sent: Wednesday, November 27, 2019 6:29 PM

> To: Allen Chen (陳柏宇)

> Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; Allen Chen (陳柏宇); open list; open 
> list:DRM DRIVERS; David Airlie; Pi-Hsun Shih; Sean Paul

> Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
> timings logic

>

>

>

> On Tue, 26 Nov 2019, allen  wrote:

>

>> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD

>

>> (Defines EDID Structure Version 1, Revision 4) page: 39

>

>> How to determine whether the monitor support RB timing or not?

>

>> EDID 1.4

>

>> First:  read detailed timing descriptor and make sure byte 0 = 0x00,

>

>> byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD

>

>> Second: read EDID bit 0 in feature support byte at address 18h = 1

>

>> and detailed timing descriptor byte 10 = 0x04

>

>> Third:  if EDID bit 0 in feature support byte = 1 &&

>

>> detailed timing descriptor byte 10 = 0x04

>

>> then we can check byte 15, if bit 4 in byte 15 = 1 is support RB

>

>> if EDID bit 0 in feature support byte != 1 ||

>

>> detailed timing descriptor byte 10 != 0x04,

>

>> then byte 15 can not be used

>

>>

>

>> The linux code is_rb function not follow the VESA's rule

>

>>

>

>> Signed-off-by: Allen Chen 

>

>> Reported-by: kbuild test robot 

>

>> ---

>

>>  drivers/gpu/drm/drm_edid.c | 36 ++--

>

>>  1 file changed, 30 insertions(+), 6 deletions(-)

>

>>

>

>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c

>

>> index f5926bf..e11e585 100644

>

>> --- a/drivers/gpu/drm/drm_edid.c

>

>> +++ b/drivers/gpu/drm/drm_edid.c

>

>> @@ -93,6 +93,12 @@ struct detailed_mode_closure {

>

>>int modes;

>

>>  };

>

>>

>

>> +struct edid_support_rb_closure {

>

>> +   struct edid *edid;

>

>> +   bool valid_support_rb;

>

>> +   bool support_rb;

>

>> +};

>

>> +

>

>>  #define LEVEL_DMT 0

>

>>  #define LEVEL_GTF   1

>

>>  #define LEVEL_GTF2 2

>

>> @@ -2017,23 +2023,41 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
>> drm_device *dev,

>

>>}

>

>>  }

>

>>

>

>> +static bool

>

>> +is_display_descriptor(const u8 *r, u8 tag)

>

>> +{

>

>> +   return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;

>

>> +}

>

>> +

>

>>  static void

>

>>  is_rb(struct detailed_timing *t, void *data)

>

>>  {

>

>>u8 *r = (u8 *)t;

>

>> -if (r[3] == EDID_DETAIL_MONITOR_RANGE)

>

>> -if (r[15] & 0x10)

>

>> -*(bool *)data = true;

>

>> +   struct edid_support_rb_closure *closure = data;

>

>> +   struct edid *edid = closure->edid;

>

>> +

>

>> +   if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {

>

>> +   if (edid->features & BIT(0) && r[10] == BIT(2)) {

>

>> +   closure->valid_support_rb = true;

>

>> +   closure->support_rb = (r[15] & 0x10) ? true : false;

>

>> +   }

>

>> +   }

>

>>  }

>

>>

>

>>  /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */

>

>>  static bool

>

>>  drm_monitor_supports_rb(struct edid *edid)

>

>>  {

>

>> +   struct edid_support_rb_closure closure = {

>

>> +   .edid = edid,

>

>> +   .valid_support_rb = false,

>

>> +   .support_rb = false,

>

>> +   };

>

>> +

>

>>if (edid->revision >= 4) {

>

>> -bool ret = false;

>

>> -drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);

>

>> -return ret;

>

>> +   drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);

>

>> +   if (closure.valid_support_rb)

>

>> +   return closure.support_rb;

>

>

>

> Are you planning on extending the closure use somehow?

>

>

>

> I did not look up the spec,

>

>

>

> ==> iTE: as the picture below, from VESA E-EDID standard

>

> [cid:image003.jpg@01D5A9EA.9B7364D0]

>

>

>

> [cid:image005.jpg@01D5A9EA.9B7364D0]

>

>

>

> if EDID bit 0 in feature support byte = 1 && detailed timing descriptor byte 
> 10 = 0x04 then the CVT timing supported.

>

>

>

> [cid:image009.jpg@01D5A9EA.9B7364D0]

>

>

>

> If CVT timing supported the

RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking timings logic

2019-12-10 Thread allen.chen
Hi Jani

Sorry to bother you. May this patch is OK to be upstream?

If have any suggestion, I will try to modify the code to meet the upstream 
standard.

From: Allen Chen (陳柏宇)
Sent: Thursday, December 05, 2019 9:24 AM
To: 'Jani Nikula'
Cc: Jau-Chih Tseng (曾昭智); maxime.rip...@bootlin.com; 
linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; 
airl...@linux.ie; pih...@chromium.org; s...@poorly.run
Subject: RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
timings logic


Hi Jani Nikula



Thanks for your suggestion and I have replied one comment below.



-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Tuesday, December 03, 2019 4:02 PM
To: Allen Chen (陳柏宇)
Cc: Jau-Chih Tseng (曾昭智); maxime.rip...@bootlin.com; 
linux-ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; 
airl...@linux.ie; pih...@chromium.org; s...@poorly.run
Subject: RE: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
timings logic



On Tue, 03 Dec 2019,  wrote:

> Hi Jani Nikula

>

>

>

> Thanks for your suggestion and I have replied two comments below.



Please read my question again.



BR,

Jani.



>

>

>

> -Original Message-

> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]

> Sent: Wednesday, November 27, 2019 6:29 PM

> To: Allen Chen (陳柏宇)

> Cc: Jau-Chih Tseng (曾昭智); Maxime Ripard; Allen Chen (陳柏宇); open list; open 
> list:DRM DRIVERS; David Airlie; Pi-Hsun Shih; Sean Paul

> Subject: Re: [PATCH] drm/edid: fixup EDID 1.3 and 1.4 judge reduced-blanking 
> timings logic

>

>

>

> On Tue, 26 Nov 2019, allen  wrote:

>

>> According to VESA ENHANCED EXTENDED DISPLAY IDENTIFICATION DATA STANDARD

>

>> (Defines EDID Structure Version 1, Revision 4) page: 39

>

>> How to determine whether the monitor support RB timing or not?

>

>> EDID 1.4

>

>> First:  read detailed timing descriptor and make sure byte 0 = 0x00,

>

>> byte 1 = 0x00, byte 2 = 0x00 and byte 3 = 0xFD

>

>> Second: read EDID bit 0 in feature support byte at address 18h = 1

>

>> and detailed timing descriptor byte 10 = 0x04

>

>> Third:  if EDID bit 0 in feature support byte = 1 &&

>

>> detailed timing descriptor byte 10 = 0x04

>

>> then we can check byte 15, if bit 4 in byte 15 = 1 is support RB

>

>> if EDID bit 0 in feature support byte != 1 ||

>

>> detailed timing descriptor byte 10 != 0x04,

>

>> then byte 15 can not be used

>

>>

>

>> The linux code is_rb function not follow the VESA's rule

>

>>

>

>> Signed-off-by: Allen Chen 

>

>> Reported-by: kbuild test robot 

>

>> ---

>

>>  drivers/gpu/drm/drm_edid.c | 36 ++--

>

>>  1 file changed, 30 insertions(+), 6 deletions(-)

>

>>

>

>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c

>

>> index f5926bf..e11e585 100644

>

>> --- a/drivers/gpu/drm/drm_edid.c

>

>> +++ b/drivers/gpu/drm/drm_edid.c

>

>> @@ -93,6 +93,12 @@ struct detailed_mode_closure {

>

>>int modes;

>

>>  };

>

>>

>

>> +struct edid_support_rb_closure {

>

>> +   struct edid *edid;

>

>> +   bool valid_support_rb;

>

>> +   bool support_rb;

>

>> +};

>

>> +

>

>>  #define LEVEL_DMT 0

>

>>  #define LEVEL_GTF   1

>

>>  #define LEVEL_GTF2 2

>

>> @@ -2017,23 +2023,41 @@ struct drm_display_mode *drm_mode_find_dmt(struct 
>> drm_device *dev,

>

>>}

>

>>  }

>

>>

>

>> +static bool

>

>> +is_display_descriptor(const u8 *r, u8 tag)

>

>> +{

>

>> +   return (!r[0] && !r[1] && !r[2] && r[3] == tag) ? true : false;

>

>> +}

>

>> +

>

>>  static void

>

>>  is_rb(struct detailed_timing *t, void *data)

>

>>  {

>

>>u8 *r = (u8 *)t;

>

>> -if (r[3] == EDID_DETAIL_MONITOR_RANGE)

>

>> -if (r[15] & 0x10)

>

>> -*(bool *)data = true;

>

>> +   struct edid_support_rb_closure *closure = data;

>

>> +   struct edid *edid = closure->edid;

>

>> +

>

>> +   if (is_display_descriptor(r, EDID_DETAIL_MONITOR_RANGE)) {

>

>> +   if (edid->features & BIT(0) && r[10] == BIT(2)) {

>

>> +   closure->valid_support_rb = true;

>

>> +   closure->support_rb = (r[15] & 0x10) ? true : false;

>

>> +   }

>

>> +   }

>

>>  }

>

>>

>

>>  /* EDID 1.4 defines this explicitly.  For EDID 1.3, we guess, badly. */

>

>>  static bool

>

>>  drm_monitor_supports_rb(struct edid *edid)

>

>>  {

>

>> +   struct edid_support_rb_closure closure = {

>

>> +   .edid = edid,

>

>> +   .valid_support_rb = false,

>

>> +   .support_rb = false,

>

>> +   };

>

>> +

>

>>if (edid->revision >= 4) {

>

>> -bool ret = false;

>

>> -drm_for_each_detailed_block((u8 *)edid, is_rb, &ret);

>

>> -return ret;

>

>> +   drm_for_each_detailed_block((u8 *)edid, is_rb, &closure);

>

>> +   if (closure.valid_support_rb)

>

>> +   return clos

RE: [PATCH v2 1/2] dt-bindings: it6505: add properties to restrict output bandwidth

2022-10-04 Thread allen.chen
Hi

data-lanes is output configuration. Maybe it is not suitable to put data-lanes 
in input endpoint.
extcon doesn't have output endpoint, so I don't know where to put is better.

-Original Message-
From: Neil Armstrong  
Sent: Thursday, September 29, 2022 4:40 PM
To: Allen Chen (陳柏宇) 
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; Kenneth Hung (洪家倫) ; 
Jernej Skrabec ; Krzysztof Kozlowski 
; Jau-Chih Tseng (曾昭智) 
; David Airlie ; open list:DRM 
DRIVERS ; Neil Armstrong 
; open list ; Robert 
Foss ; Pin-yen Lin ; Hermes Wu 
(吳佳宏) ; Rob Herring ; Laurent 
Pinchart ; Andrzej Hajda 
; Jonas Karlman 
Subject: Re: [PATCH v2 1/2] dt-bindings: it6505: add properties to restrict 
output bandwidth

Hi,

On 29/09/2022 03:44, allen wrote:
> From: allen chen 
> 
> Add properties to restrict dp output data-lanes and clock.
> 
> Signed-off-by: Pin-Yen Lin 
> Signed-off-by: Allen Chen 
> ---
>   .../devicetree/bindings/display/bridge/ite,it6505.yaml | 10 ++
>   1 file changed, 10 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> index 833d11b2303a..62b9f2192202 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> @@ -52,6 +52,14 @@ properties:
>   maxItems: 1
>   description: extcon specifier for the Power Delivery
>   
> +  data-lanes:
> +maxItems: 1
> +description: restrict the dp output data-lanes with value of 1-4

Can't you use the data-lanes property in the first port endpoint ?

Look at Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml

> +
> +  max-pixel-clock-khz:
> +maxItems: 1
> +description: restrict max pixel clock

New vendor specific properties should have the ite, prefix.

> +
> port:
>   $ref: /schemas/graph.yaml#/properties/port
>   description: A port node pointing to DPI host port node @@ -84,6 
> +92,8 @@ examples:
>   pwr18-supply = <&it6505_pp18_reg>;
>   reset-gpios = <&pio 179 1>;
>   extcon = <&usbc_extcon>;
> +data-lanes = <2>;
> +max-pixel-clock-khz = <15>;
>   
>   port {
>   it6505_in: endpoint {

Thanks,
Neil


RE: [PATCH v3 1/2] dt-bindings: it6505: add properties to restrict output bandwidth

2022-10-06 Thread allen.chen
hi

-Original Message-
From: Krzysztof Kozlowski  
Sent: Thursday, October 6, 2022 4:17 PM
To: Allen Chen (陳柏宇) 
Cc: Jau-Chih Tseng (曾昭智) ; Kenneth Hung (洪家倫) 
; Hermes Wu (吳佳宏) ; Pin-yen Lin 
; Andrzej Hajda ; Neil 
Armstrong ; Robert Foss ; 
Laurent Pinchart ; Jonas Karlman 
; Jernej Skrabec ; David Airlie 
; Daniel Vetter ; Rob Herring 
; Krzysztof Kozlowski ; 
open list:DRM DRIVERS ; open list:OPEN 
FIRMWARE AND FLATTENED DEVICE TREE BINDINGS ; open 
list 
Subject: Re: [PATCH v3 1/2] dt-bindings: it6505: add properties to restrict 
output bandwidth

On 06/10/2022 04:04, allen wrote:
> From: allen chen 
> 
> Add properties to restrict dp output data-lanes and clock.
> 
> Signed-off-by: Pin-Yen Lin 
> Signed-off-by: Allen Chen 
> ---
>  .../bindings/display/bridge/ite,it6505.yaml  | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> index 833d11b2303a..f5482a614d05 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> @@ -52,6 +52,16 @@ properties:
>  maxItems: 1
>  description: extcon specifier for the Power Delivery
>  
> +  ite,dp-output-data-lane-count:
> +description: restrict the dp output data-lanes with value of 1-4

Drop "with value of 1-4" because it is redundant, but instead explain what this 
property is about. "Restrict output" is not yet enough.
Restrict the number? Or choose specific lanes? Why it cannot be data-lanes from 
video-interfaces?

==> DP output bandwidth depends on data-lane-count, so the number of output 
data-lane-count will restrict output bandwidth.
In this dt-binding we don't have output endpoint, so use another property name 
to configure.
If need to use data-lanes, where can we put in this dt-binding?

> +$ref: /schemas/types.yaml#/definitions/uint32
> +enum: [ 1, 2, 4 ]
> +
> +  ite,dp-output-max-pixel-clock-mhz:

Test your patches before sending.

Best regards,
Krzysztof



RE: [PATCH v4 1/2] dt-bindings: it6505: add properties to restrict output bandwidth

2022-10-13 Thread allen.chen
Hi

-Original Message-
From: Rob Herring  
Sent: Friday, October 14, 2022 3:20 AM
To: Laurent Pinchart ; Allen Chen (陳柏宇) 

Cc: Pin-yen Lin ; Jau-Chih Tseng (曾昭智) 
; Kenneth Hung (洪家倫) ; 
Hermes Wu (吳佳宏) ; Andrzej Hajda 
; Neil Armstrong ; Robert 
Foss ; Jonas Karlman ; Jernej Skrabec 
; David Airlie ; Daniel Vetter 
; Krzysztof Kozlowski ; 
open list:DRM DRIVERS ; open list:OPEN 
FIRMWARE AND FLATTENED DEVICE TREE BINDINGS ; open 
list 
Subject: Re: [PATCH v4 1/2] dt-bindings: it6505: add properties to restrict 
output bandwidth

On Thu, Oct 13, 2022 at 02:05:45PM +0300, Laurent Pinchart wrote:
> Hi Allen,
> 
> Thank you for the patch.
> 
> On Thu, Oct 13, 2022 at 06:51:13PM +0800, allen wrote:
> > From: allen chen 
> > 
> > Add properties to restrict dp output data-lanes and clock.
> > 
> > Signed-off-by: Pin-Yen Lin 
> > Signed-off-by: Allen Chen 
> > ---
> >  .../bindings/display/bridge/ite,it6505.yaml   | 43 +++
> >  1 file changed, 43 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> > index 833d11b2303a7..f2c3d1d10359e 100644
> > --- 
> > a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.ya
> > +++ ml
> > @@ -52,10 +52,51 @@ properties:
> >  maxItems: 1
> >  description: extcon specifier for the Power Delivery
> >  
> > +  data-lanes:
> > +oneOf:
> > +  - minItems: 1
> > +maxItems: 1
> > +uniqueItems: true
> > +items:
> > +  enum:
> > +- 0
> > +- 1
> > +description: For one lane operation.
> > +
> > +  - minItems: 2
> > +maxItems: 2
> > +uniqueItems: true
> > +items:
> > +  enum:
> > +- 0
> > +- 1
> > +description: For two lanes operation.
> > +
> > +  - minItems: 4
> > +maxItems: 4
> > +uniqueItems: true
> > +items:
> > +  enum:
> > +- 0
> > +- 1
> > +- 2
> > +- 3
> > +description: For four lanes operation.
> 
> The data lanes should be in the output endpoint. If there's no output 
> port, one should be added.
> 
==> In this dt-binding, our output point is "extcon" so doesn't have output 
endpoint.
I don't know how to add the endpoint.
If need to add the endpoint to this dt-binding, what is your recommend about 
adding the endpoint?
By the way, Krzysztof Kozlowski  said we could 
put "data-lanes" here.
> > +
> >port:
> >  $ref: /schemas/graph.yaml#/properties/port

To fix the error, this must be:

$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false

> >  description: A port node pointing to DPI host port node
> >  
> > +properties:
> > +  endpoint:
> > +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> > +
> > +properties:
> > +  link-frequencies:
> > +minItems: 1
> > +maxItems: 1
> > +description: Allowed max link frequencies in Hz.
> > +
> >  required:
> >- compatible
> >- ovdd-supply
> > @@ -84,10 +125,12 @@ examples:
> >  pwr18-supply = <&it6505_pp18_reg>;
> >  reset-gpios = <&pio 179 1>;
> >  extcon = <&usbc_extcon>;
> > +data-lanes = <0 1>;
> >  
> >  port {
> >  it6505_in: endpoint {
> >  remote-endpoint = <&dpi_out>;
> > +link-frequencies = /bits/ 64 <15000>;
> >  };
> >  };
> >  };
> 
> --
> Regards,
> 
> Laurent Pinchart
> 


RE: [PATCH v4 3/3] drm/bridge: it6505: handle HDCP request

2022-11-14 Thread allen.chen
Hi

reviewed-by: allen chen 

-Original Message-
From: Hsin-Yi Wang  
Sent: Monday, November 14, 2022 4:04 PM
To: Sean Paul ; Douglas Anderson 
; Robert Foss 
Cc: Maarten Lankhorst ; Maxime Ripard 
; Thomas Zimmermann ; Daniel Vetter 
; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org; Allen Chen (陳柏宇) ; David 
Airlie 
Subject: [PATCH v4 3/3] drm/bridge: it6505: handle HDCP request

it6505 supports HDCP 1.3, but current implementation lacks the update of HDCP 
status through drm_hdcp_update_content_protection(). it6505 default enables the 
HDCP. If user set it to undesired then the driver will stop HDCP.

Signed-off-by: Hsin-Yi Wang 
---
Include it6505[1] to the series.

[1] 
https://patchwork.kernel.org/project/dri-devel/patch/20221101112009.1067681-1-hsi...@chromium.org/
---
 drivers/gpu/drm/bridge/ite-it6505.c | 55 +
 1 file changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index 21a9b8422bda..be08b42de4ea 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -423,6 +423,7 @@ struct it6505 {
struct extcon_dev *extcon;
struct work_struct extcon_wq;
int extcon_state;
+   struct drm_connector *connector;
enum drm_connector_status connector_status;
enum link_train_status link_state;
struct work_struct link_works;
@@ -2399,6 +2400,14 @@ static void it6505_irq_hdcp_done(struct it6505 *it6505)
 
DRM_DEV_DEBUG_DRIVER(dev, "hdcp done interrupt");
it6505->hdcp_status = HDCP_AUTH_DONE;
+   if (it6505->connector) {
+   struct drm_device *drm_dev = it6505->connector->dev;
+
+   drm_modeset_lock(&drm_dev->mode_config.connection_mutex, NULL);
+   drm_hdcp_update_content_protection(it6505->connector,
+  
DRM_MODE_CONTENT_PROTECTION_ENABLED);
+   drm_modeset_unlock(&drm_dev->mode_config.connection_mutex);
+   }
it6505_show_hdcp_info(it6505);
 }
 
@@ -2931,6 +2940,7 @@ static void it6505_bridge_atomic_enable(struct drm_bridge 
*bridge,
if (WARN_ON(!connector))
return;
 
+   it6505->connector = connector;
conn_state = drm_atomic_get_new_connector_state(state, connector);
 
if (WARN_ON(!conn_state))
@@ -2974,6 +2984,7 @@ static void it6505_bridge_atomic_disable(struct 
drm_bridge *bridge,
 
DRM_DEV_DEBUG_DRIVER(dev, "start");
 
+   it6505->connector = NULL;
if (it6505->powered) {
it6505_drm_dp_link_set_power(&it6505->aux, &it6505->link,
 DP_SET_POWER_D3);
@@ -3028,6 +3039,48 @@ static struct edid *it6505_bridge_get_edid(struct 
drm_bridge *bridge,
return edid;
 }
 
+static int it6505_connector_atomic_check(struct it6505 *it6505,
+struct drm_connector_state *state) {
+   struct device *dev = &it6505->client->dev;
+   int cp = state->content_protection;
+
+   DRM_DEV_DEBUG_DRIVER(dev, "hdcp connector state:%d, curr hdcp state:%d",
+cp, it6505->hdcp_status);
+
+   if (!it6505->hdcp_desired) {
+   DRM_DEV_DEBUG_DRIVER(dev, "sink not support hdcp");
+   return 0;
+   }
+
+   if (it6505->hdcp_status == HDCP_AUTH_GOING)
+   return -EINVAL;
+
+   if (cp == DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
+   if (it6505->hdcp_status == HDCP_AUTH_DONE)
+   it6505_stop_hdcp(it6505);
+   } else if (cp == DRM_MODE_CONTENT_PROTECTION_DESIRED) {
+   if (it6505->hdcp_status == HDCP_AUTH_IDLE &&
+   it6505->link_state == LINK_OK)
+   it6505_start_hdcp(it6505);
+   } else {
+   DRM_DEV_DEBUG_DRIVER(dev, "invalid to set hdcp enabled");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int it6505_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state) {
+   struct it6505 *it6505 = bridge_to_it6505(bridge);
+
+   return it6505_connector_atomic_check(it6505, conn_state); }
+
 static const struct drm_bridge_funcs it6505_bridge_funcs = {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
@@ -3035,6 +3088,7 @@ static const struct drm_bridge_funcs it6505_bridge_funcs 
= {
.attach = it6505_bridge_attach,
.detach = it6505_bridge_detach,
.mode_valid = it6505_bridge_mode_valid,
+   .atomic_check = it6505_bridge_atomic_check,
.atomic_enable = it6505_bridge_atomic_enable,
.atomic_disable = i

RE: [PATCH v5 1/2] dt-bindings: it6505: add properties to restrict output bandwidth

2022-10-26 Thread allen.chen
Hi rob

-Original Message-
From: Rob Herring  
Sent: Tuesday, October 25, 2022 12:38 AM
To: Allen Chen (陳柏宇) 
Cc: Pin-Yen Lin ; Jau-Chih Tseng (曾昭智) 
; Hermes Wu (吳佳宏) ; Kenneth 
Hung (洪家倫) ; Andrzej Hajda ; 
Neil Armstrong ; Robert Foss ; 
Laurent Pinchart ; Jonas Karlman 
; Jernej Skrabec ; David Airlie 
; Daniel Vetter ; Krzysztof Kozlowski 
; open list:DRM DRIVERS 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE 
TREE BINDINGS ; open list 

Subject: Re: [PATCH v5 1/2] dt-bindings: it6505: add properties to restrict 
output bandwidth

On Wed, Oct 19, 2022 at 05:32:13PM +0800, allen wrote:
> From: allen chen 
> 
> Add properties to restrict dp output data-lanes and clock.
> 
> Signed-off-by: Pin-Yen Lin 
> Signed-off-by: Allen Chen 
> ---
>  .../bindings/display/bridge/ite,it6505.yaml   | 89 +--
>  1 file changed, 83 insertions(+), 6 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> index 833d11b2303a7..8e607b6929fc9 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> @@ -52,9 +52,70 @@ properties:
>  maxItems: 1
>  description: extcon specifier for the Power Delivery
>  
> -  port:
> -$ref: /schemas/graph.yaml#/properties/port
> -description: A port node pointing to DPI host port node

No existing users you are breaking? The commit msg should explain.

==> There are no it6505 users in community.
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +unevaluatedProperties: false
> +description: A port node pointing to DPI host port node
> +
> +properties:
> +  endpoint:
> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> +unevaluatedProperties: false
> +
> +properties:
> +  link-frequencies:
> +minItems: 1
> +maxItems: 1
> +description: Allowed max link frequencies in Hz
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +unevaluatedProperties: false
> +description: Video port for DP output
> +
> +properties:
> +  endpoint:
> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> +unevaluatedProperties: false
> +
> +properties:
> +  data-lanes:
> +oneOf:
> +  - minItems: 1
> +maxItems: 1
> +uniqueItems: true
> +items:
> +  enum:
> +- 0
> +- 1
> +description: For one lane operation.
> +
> +  - minItems: 2
> +maxItems: 2
> +uniqueItems: true
> +items:
> +  enum:
> +- 0
> +- 1
> +description: For two lanes operation.
> +
> +  - minItems: 4
> +maxItems: 4
> +uniqueItems: true
> +items:
> +  enum:
> +- 0
> +- 1
> +- 2
> +- 3
> +description: For four lanes operation.

I would do just:

data-lanes:
  minItems: 1
  items:
- enum: [ 0, 1 ]
- const: 1
- const: 2
- const: 3

It does allow 3 lanes, but I don't think that's a big deal. What it does 
doesn't allow is any order and yours does.

Rob


RE: [PATCH v6 1/2] dt-bindings: it6505: add properties to restrict output bandwidth

2022-11-01 Thread allen.chen
hi

-Original Message-
From: Krzysztof Kozlowski  
Sent: Friday, October 28, 2022 9:59 AM
To: Allen Chen (陳柏宇) 
Cc: Pin-Yen Lin ; Jau-Chih Tseng (曾昭智) 
; Hermes Wu (吳佳宏) ; Kenneth 
Hung (洪家倫) ; Andrzej Hajda ; 
Neil Armstrong ; Robert Foss ; 
Laurent Pinchart ; Jonas Karlman 
; Jernej Skrabec ; David Airlie 
; Daniel Vetter ; Rob Herring 
; Krzysztof Kozlowski ; 
open list:DRM DRIVERS ; open list:OPEN 
FIRMWARE AND FLATTENED DEVICE TREE BINDINGS ; open 
list 
Subject: Re: [PATCH v6 1/2] dt-bindings: it6505: add properties to restrict 
output bandwidth

On 26/10/2022 23:01, allen wrote:
> From: allen chen 
> 
> Add properties to restrict dp output data-lanes and clock.

This is a friendly reminder during the review process.

It seems my previous comments were not fully addressed. Maybe my feedback got 
lost between the quotes, maybe you just forgot to apply it.
Please go back to the previous discussion and either implement all requested 
changes or keep discussing them.

Thank you.

==> I am sorry I didn't find the missing advice you said. Could you explain it 
again?

Rob asked - Commit msg should explain reason for breaking users.

> 
> Signed-off-by: Pin-Yen Lin 
> Signed-off-by: Allen Chen 
> ---
>  .../bindings/display/bridge/ite,it6505.yaml   | 68 +--
>  1 file changed, 62 insertions(+), 6 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml 
> b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> index 833d11b2303a7..b16a9d9127ddb 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
> @@ -52,9 +52,49 @@ properties:
>  maxItems: 1
>  description: extcon specifier for the Power Delivery
>  
> -  port:
> -$ref: /schemas/graph.yaml#/properties/port
> -description: A port node pointing to DPI host port node
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +unevaluatedProperties: false
> +description: A port node pointing to DPI host port node
> +
> +properties:
> +  endpoint:
> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> +unevaluatedProperties: false
> +
> +properties:
> +  link-frequencies:
> +minItems: 1
> +maxItems: 1
> +description: Allowed max link frequencies in Hz
> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +unevaluatedProperties: false
> +description: Video port for DP output
> +
> +properties:
> +  endpoint:
> +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> +unevaluatedProperties: false
> +
> +properties:
> +  data-lanes:
> +minItems: 1
> +uniqueItems: true
> +items:
> +  - enum: [ 0, 1 ]
> +  - const: 1
> +  - const: 2
> +  - const: 3
> +

This looks ok.

Best regards,
Krzysztof



RE: [PATCH v6 1/2] dt-bindings: it6505: add properties to restrict output bandwidth

2022-11-03 Thread allen.chen
hi

-Original Message-
From: Krzysztof Kozlowski  
Sent: Thursday, November 3, 2022 12:34 AM
To: Allen Chen (陳柏宇) 
Cc: treapk...@chromium.org; Jau-Chih Tseng (曾昭智) ; 
Hermes Wu (吳佳宏) ; Kenneth Hung (洪家倫) 
; andrzej.ha...@intel.com; narmstr...@baylibre.com; 
robert.f...@linaro.org; laurent.pinch...@ideasonboard.com; jo...@kwiboo.se; 
jernej.skra...@gmail.com; airl...@linux.ie; dan...@ffwll.ch; 
robh...@kernel.org; krzysztof.kozlowski...@linaro.org; 
dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; 
linux-ker...@vger.kernel.org
Subject: Re: [PATCH v6 1/2] dt-bindings: it6505: add properties to restrict 
output bandwidth

On 02/11/2022 02:54, allen.c...@ite.com.tw wrote:
> On 26/10/2022 23:01, allen wrote:
>> From: allen chen 
>>
>> Add properties to restrict dp output data-lanes and clock.
> 
> This is a friendly reminder during the review process.
> 
> It seems my previous comments were not fully addressed. Maybe my feedback got 
> lost between the quotes, maybe you just forgot to apply it.
> Please go back to the previous discussion and either implement all requested 
> changes or keep discussing them.
> 
> Thank you.
> 
> ==> I am sorry I didn't find the missing advice you said. Could you explain 
> it again?
> 
> Rob asked - Commit msg should explain reason for breaking users.

And where is the reason? I saw only one sentence "Add properties to restrict dp 
output data-lanes and clock."
==> I will add the commit msg in v7. Thanks for the suggestion.

Best regards,
Krzysztof



RE: [PATCH v3] drm/bridge: add it6505 driver

2020-10-21 Thread allen.chen
Hi sam

This bridge will be used with 
mtk_dpi.c(https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/mediatek/mtk_dpi.c).

Thanks for your comments.

-Original Message-
From: Sam Ravnborg [mailto:s...@ravnborg.org] 
Sent: Saturday, October 17, 2020 3:27 PM
To: Allen Chen (陳柏宇)
Cc: Kenneth Hung (洪家倫); Jitao Shi; kernel test robot; Jau-Chih Tseng (曾昭智); 
Yilun Lin; David Airlie; Neil Armstrong; Jernej Skrabec; open list:DRM DRIVERS; 
open list; Andrzej Hajda; Hermes Wu (吳佳宏); moderated list:ARM/Mediatek SoC 
support; Laurent Pinchart; Pi-Hsun Shih; Matthias Brugger; moderated 
list:ARM/Mediatek SoC support; Jonas Karlman
Subject: Re: [PATCH v3] drm/bridge: add it6505 driver

Hi Allen

On Fri, Sep 04, 2020 at 10:10:23AM +0800, allen wrote:
> This adds support for the iTE IT6505.
> This device can convert DPI signal to DP output.
> 
> From: Allen Chen 
> Signed-off-by: Jitao Shi 
> Signed-off-by: Pi-Hsun Shih 
> Signed-off-by: Yilun Lin 
> Signed-off-by: Hermes Wu 
> Signed-off-by: Allen Chen 
> Reported-by: kernel test robot 


Sorry for being so late with the feedback - have been offline for a
while.

One high-level comment - the bridge does not respect the flags arguments
in the it6505_bridge_attach function. And will unconditionally create the
connector.

The correct approach is that the display driver creates the connector,
and pass a flag to the bridge driver to tell it not to create the
connector.

Could we please update the relevant display drivers to create the
connector and then drop it from the bridge driver. So we avoid adding
backward compatible code to a new bridge driver.

What display driver will this bridge be used with?

Sam

> ---
>  drivers/gpu/drm/bridge/Kconfig  |7 +
>  drivers/gpu/drm/bridge/Makefile |1 +
>  drivers/gpu/drm/bridge/ite-it6505.c | 3338 +++
>  3 files changed, 3346 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3e11af4e9f63e..f21dce3fabeb9 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -61,6 +61,13 @@ config DRM_LONTIUM_LT9611
> HDMI signals
> Please say Y if you have such hardware.
>  
> +config DRM_ITE_IT6505
> + tristate "ITE IT6505 DisplayPort bridge"
> + depends on OF
> + select DRM_KMS_HELPER
> + help
> +   ITE IT6505 DisplayPort bridge chip driver.
> +
>  config DRM_LVDS_CODEC
>   tristate "Transparent LVDS encoders and decoders support"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index c589a6a7cbe1d..8a118fd901ad7 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
>  obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
>  obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
>  obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> +obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
>  obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
>  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> megachips-stdp-ge-b850v3-fw.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
> b/drivers/gpu/drm/bridge/ite-it6505.c
> new file mode 100644
> index 0..0ed19673431ee
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/ite-it6505.c
> @@ -0,0 +1,3338 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define REG_IC_VER 0x04
> +
> +#define REG_RESET_CTRL 0x05
> +#define VIDEO_RESET BIT(0)
> +#define AUDIO_RESET BIT(1)
> +#define ALL_LOGIC_RESET BIT(2)
> +#define AUX_RESET BIT(3)
> +#define HDCP_RESET BIT(4)
> +
> +#define INT_STATUS_01 0x06
> +#define INT_MASK_01 0x09
> +#define INT_HPD_CHANGE BIT(0)
> +#define INT_RECEIVE_HPD_IRQ BIT(1)
> +#define INT_SCDT_CHANGE BIT(2)
> +#define INT_HDCP_FAIL BIT(3)
> +#define INT_HDCP_DONE BIT(4)
> +
> +#define INT_STATUS_02 0x07
> +#define INT_MASK_02 0x0A
> +#define INT_AUX_CMD_FAIL BIT(0)
> +#define INT_HDCP_KSV_CHECK BIT(1)
> +#define INT_AUDIO_FIFO_ERROR BIT(2)
> +
> +#define INT_STATUS_03 0x08
> +#define INT_MASK_03 0x0B
> +#define INT_LINK_TRAIN_FAIL BIT(4)
> +#define INT_VID_FIFO_ERROR BIT(5)
> +#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7)
> +
> +#define REG_SYSTEM_STS 0x0D
> +#define INT_STS BIT(0)
> +#define HPD_STS BIT(1)
> +#define VIDEO_STB BIT(2)
> +
> +#define REG_LINK_TRAIN_STS 0x0E
> +#d

RE: [PATCH v3] drm/bridge: add it6505 driver

2020-09-18 Thread allen.chen
It has been about two weeks since I posted v3 and haven't heard anything.
Consider this a gentle ping.

If there is something need to fix. I will fix and upstream again.

Thanks.

-Original Message-
From: Allen Chen (陳柏宇) 
Sent: Friday, September 04, 2020 10:10 AM
Cc: Allen Chen (陳柏宇); Kenneth Hung (洪家倫); Jau-Chih Tseng (曾昭智); Hermes Wu 
(吳佳宏); Pi-Hsun Shih; Jitao Shi; Yilun Lin; Hermes Wu (吳佳宏); kernel test robot; 
Andrzej Hajda; Neil Armstrong; Laurent Pinchart; Jonas Karlman; Jernej Skrabec; 
David Airlie; Daniel Vetter; Matthias Brugger; open list; open list:DRM 
DRIVERS; moderated list:ARM/Mediatek SoC support; moderated list:ARM/Mediatek 
SoC support
Subject: [PATCH v3] drm/bridge: add it6505 driver

This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.

From: Allen Chen 
Signed-off-by: Jitao Shi 
Signed-off-by: Pi-Hsun Shih 
Signed-off-by: Yilun Lin 
Signed-off-by: Hermes Wu 
Signed-off-by: Allen Chen 
Reported-by: kernel test robot 
---
 drivers/gpu/drm/bridge/Kconfig  |7 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ite-it6505.c | 3338 +++
 3 files changed, 3346 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e11af4e9f63e..f21dce3fabeb9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -61,6 +61,13 @@ config DRM_LONTIUM_LT9611
  HDMI signals
  Please say Y if you have such hardware.
 
+config DRM_ITE_IT6505
+   tristate "ITE IT6505 DisplayPort bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ ITE IT6505 DisplayPort bridge chip driver.
+
 config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c589a6a7cbe1d..8a118fd901ad7 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index 0..0ed19673431ee
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1,3338 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define REG_IC_VER 0x04
+
+#define REG_RESET_CTRL 0x05
+#define VIDEO_RESET BIT(0)
+#define AUDIO_RESET BIT(1)
+#define ALL_LOGIC_RESET BIT(2)
+#define AUX_RESET BIT(3)
+#define HDCP_RESET BIT(4)
+
+#define INT_STATUS_01 0x06
+#define INT_MASK_01 0x09
+#define INT_HPD_CHANGE BIT(0)
+#define INT_RECEIVE_HPD_IRQ BIT(1)
+#define INT_SCDT_CHANGE BIT(2)
+#define INT_HDCP_FAIL BIT(3)
+#define INT_HDCP_DONE BIT(4)
+
+#define INT_STATUS_02 0x07
+#define INT_MASK_02 0x0A
+#define INT_AUX_CMD_FAIL BIT(0)
+#define INT_HDCP_KSV_CHECK BIT(1)
+#define INT_AUDIO_FIFO_ERROR BIT(2)
+
+#define INT_STATUS_03 0x08
+#define INT_MASK_03 0x0B
+#define INT_LINK_TRAIN_FAIL BIT(4)
+#define INT_VID_FIFO_ERROR BIT(5)
+#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7)
+
+#define REG_SYSTEM_STS 0x0D
+#define INT_STS BIT(0)
+#define HPD_STS BIT(1)
+#define VIDEO_STB BIT(2)
+
+#define REG_LINK_TRAIN_STS 0x0E
+#define LINK_STATE_CR BIT(2)
+#define LINK_STATE_EQ BIT(3)
+#define LINK_STATE_NORP BIT(4)
+
+#define REG_BANK_SEL 0x0F
+#define REG_CLK_CTRL0 0x10
+#define M_PCLK_DELAY 0x03
+
+#define REG_AUX_OPT 0x11
+#define AUX_AUTO_RST BIT(0)
+#define AUX_FIX_FREQ BIT(3)
+
+#define REG_DATA_CTRL0 0x12
+#define VIDEO_LATCH_EDGE BIT(4)
+#define ENABLE_PCLK_COUNTER BIT(7)
+
+#define REG_PCLK_COUNTER_VALUE 0x13
+
+#define REG_501_FIFO_CTRL 0x15
+#define RST_501_FIFO BIT(1)
+
+#define REG_TRAIN_CTRL0 0x16
+#define FORCE_LBR BIT(0)
+#define LANE_COUNT_MASK 0x06
+#define LANE_SWAP BIT(3)
+#define SPREAD_AMP_5 BIT(4)
+#define FORCE_CR_DONE BIT(5)
+#define FORCE_EQ_DONE BIT(6)
+
+#define REG_TRAIN_CTRL1 0x17
+#define AUTO_TRAIN BIT(0)
+#define MANUAL_TRAIN BIT(1)
+#define FORCE_RETRAIN BIT(2)
+
+#define REG_AUX_CTRL 0x23
+#define CLR_EDID_FIFO BIT(0)
+#define AUX_USER_MODE BIT(1)
+#define AUX_NO_SEGMENT_WR BIT(6)
+#define A