* [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for R40 HDMI pipeline. It is a bit special
than other already supported pipelines because it has additional unit
called TCON TOP responsible for relationship configuration between
mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
and TV TCONs, TV encoder clock settings and pin muxing between LCD
and TV encoders.
However, it seems that TCON TOP will become a norm, since newer
Allwinner SoCs like H6 also have this unit.
I tested different possible configurations:
- mixer0 <> TCON-TV0 <> HDMI
- mixer0 <> TCON-TV1 <> HDMI
- mixer1 <> TCON-TV0 <> HDMI
- mixer1 <> TCON-TV1 <> HDMI
Please review.
Best regards,
Jernej
Changes from v1:
- Split DT bindings patch and updated description
- Split HDMI PHY patch
- Move header file from TCON TOP patch to dt bindings patch
- Added Rob reviewed-by tag
- Used clk_hw_register_gate() instead of custom gate registration code
- Reworked TCON TOP to be part of of-graph. Because of that, a lot of
new patches were added.
- Droped mixer index quirk patch
- Reworked TCON support for TCON TOP
- Updated commit messages
Jernej Skrabec (27):
clk: sunxi-ng: r40: Add minimal rate for video PLLs
clk: sunxi-ng: r40: Allow setting parent rate to display related
clocks
clk: sunxi-ng: r40: Export video PLLs
dt-bindings: display: sunxi-drm: Add TCON TOP description
drm/sun4i: Add TCON TOP driver
drm/sun4i: Fix releasing node when enumerating enpoints
drm/sun4i: Split out code for enumerating endpoints in output port
drm/sun4i: Add support for traversing graph with TCON TOP
drm/sun4i: Don't skip TCONs if they don't have channel 0
dt-bindings: display: sun4i-drm: Add R40 TV TCON description
drm/sun4i: tcon: Add support for tcon-top gate
drm/sun4i: tcon: Generalize engine search algorithm
drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
drm/sun4i: Don't check for panel or bridge on TV TCONs
drm/sun4i: Add support for R40 TV TCON
dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
drm/sun4i: Add support for R40 mixers
dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
drm/sun4i: Enable DW HDMI PHY clock
drm/sun4i: Don't change clock bits in DW HDMI PHY driver
drm/sun4i: DW HDMI PHY: Add support for second PLL
drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
driver
drm/sun4i: Add support for A64 HDMI PHY
drm: of: Export drm_crtc_port_mask()
drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
ARM: dts: sun8i: r40: Add HDMI pipeline
ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
.../bindings/display/sunxi/sun4i-drm.txt | 56 +++-
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++
arch/arm/boot/dts/sun8i-r40.dtsi | 257 ++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 58 ++--
drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 +-
drivers/gpu/drm/drm_of.c | 4 +-
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 121 ++++++---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 83 ++++--
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 46 +++-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 8 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 54 +++-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 ++++--
drivers/gpu/drm/sun4i/sun8i_mixer.c | 24 ++
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 248 +++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 38 +++
include/drm/drm_of.h | 8 +
include/dt-bindings/clock/sun8i-r40-ccu.h | 4 +
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +
20 files changed, 1047 insertions(+), 123 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
--
2.17.1
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
This series adds support for R40 HDMI pipeline. It is a bit special
than other already supported pipelines because it has additional unit
called TCON TOP responsible for relationship configuration between
mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
and TV TCONs, TV encoder clock settings and pin muxing between LCD
and TV encoders.
However, it seems that TCON TOP will become a norm, since newer
Allwinner SoCs like H6 also have this unit.
I tested different possible configurations:
- mixer0 <> TCON-TV0 <> HDMI
- mixer0 <> TCON-TV1 <> HDMI
- mixer1 <> TCON-TV0 <> HDMI
- mixer1 <> TCON-TV1 <> HDMI
Please review.
Best regards,
Jernej
Changes from v1:
- Split DT bindings patch and updated description
- Split HDMI PHY patch
- Move header file from TCON TOP patch to dt bindings patch
- Added Rob reviewed-by tag
- Used clk_hw_register_gate() instead of custom gate registration code
- Reworked TCON TOP to be part of of-graph. Because of that, a lot of
new patches were added.
- Droped mixer index quirk patch
- Reworked TCON support for TCON TOP
- Updated commit messages
Jernej Skrabec (27):
clk: sunxi-ng: r40: Add minimal rate for video PLLs
clk: sunxi-ng: r40: Allow setting parent rate to display related
clocks
clk: sunxi-ng: r40: Export video PLLs
dt-bindings: display: sunxi-drm: Add TCON TOP description
drm/sun4i: Add TCON TOP driver
drm/sun4i: Fix releasing node when enumerating enpoints
drm/sun4i: Split out code for enumerating endpoints in output port
drm/sun4i: Add support for traversing graph with TCON TOP
drm/sun4i: Don't skip TCONs if they don't have channel 0
dt-bindings: display: sun4i-drm: Add R40 TV TCON description
drm/sun4i: tcon: Add support for tcon-top gate
drm/sun4i: tcon: Generalize engine search algorithm
drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
drm/sun4i: Don't check for panel or bridge on TV TCONs
drm/sun4i: Add support for R40 TV TCON
dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
drm/sun4i: Add support for R40 mixers
dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
drm/sun4i: Enable DW HDMI PHY clock
drm/sun4i: Don't change clock bits in DW HDMI PHY driver
drm/sun4i: DW HDMI PHY: Add support for second PLL
drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
driver
drm/sun4i: Add support for A64 HDMI PHY
drm: of: Export drm_crtc_port_mask()
drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
ARM: dts: sun8i: r40: Add HDMI pipeline
ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
.../bindings/display/sunxi/sun4i-drm.txt | 56 +++-
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++
arch/arm/boot/dts/sun8i-r40.dtsi | 257 ++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 58 ++--
drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 +-
drivers/gpu/drm/drm_of.c | 4 +-
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 121 ++++++---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 83 ++++--
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 46 +++-
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 8 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 54 +++-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 ++++--
drivers/gpu/drm/sun4i/sun8i_mixer.c | 24 ++
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 248 +++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 38 +++
include/drm/drm_of.h | 8 +
include/dt-bindings/clock/sun8i-r40-ccu.h | 4 +
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +
20 files changed, 1047 insertions(+), 123 deletions(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
--
2.17.1
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.
Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 46 +++++++++++++++-------------
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c16a62a7bdbd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -65,17 +65,18 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
- "osc24M", 0x0010,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video0_clk, "pll-video0",
+ "osc24M", 0x0010,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
@@ -151,17 +152,18 @@ static struct ccu_nk pll_periph1_clk = {
};
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
- "osc24M", 0x030,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video1_clk, "pll-video1",
+ "osc24M", 0x030,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
static struct ccu_nkm pll_sata_clk = {
.enable = BIT(31),
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.
Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 46 +++++++++++++++-------------
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c16a62a7bdbd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -65,17 +65,18 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
- "osc24M", 0x0010,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video0_clk, "pll-video0",
+ "osc24M", 0x0010,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
@@ -151,17 +152,18 @@ static struct ccu_nk pll_periph1_clk = {
};
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
- "osc24M", 0x030,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video1_clk, "pll-video1",
+ "osc24M", 0x030,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
static struct ccu_nkm pll_sata_clk = {
.enable = BIT(31),
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: mark.rutland, devicetree, airlied, gustavo, maarten.lankhorst,
linux-kernel, dri-devel, linux-sunxi, seanpaul, linux-clk,
linux-arm-kernel
According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.
Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 46 +++++++++++++++-------------
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c16a62a7bdbd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -65,17 +65,18 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
- "osc24M", 0x0010,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video0_clk, "pll-video0",
+ "osc24M", 0x0010,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
@@ -151,17 +152,18 @@ static struct ccu_nk pll_periph1_clk = {
};
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
- "osc24M", 0x030,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video1_clk, "pll-video1",
+ "osc24M", 0x030,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
static struct ccu_nkm pll_sata_clk = {
.enable = BIT(31),
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
According to documentation and experience with other similar SoCs, video
PLLs don't work stable if their output frequency is set below 192 MHz.
Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 46 +++++++++++++++-------------
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index 933f2e68f42a..c16a62a7bdbd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -65,17 +65,18 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video0_clk, "pll-video0",
- "osc24M", 0x0010,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video0_clk, "pll-video0",
+ "osc24M", 0x0010,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
/* TODO: The result of N/M is required to be in [8, 25] range. */
static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
@@ -151,17 +152,18 @@ static struct ccu_nk pll_periph1_clk = {
};
/* TODO: The result of N/M is required to be in [8, 25] range. */
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video1_clk, "pll-video1",
- "osc24M", 0x030,
- 8, 7, /* N */
- 0, 4, /* M */
- BIT(24), /* frac enable */
- BIT(25), /* frac select */
- 270000000, /* frac rate 0 */
- 297000000, /* frac rate 1 */
- BIT(31), /* gate */
- BIT(28), /* lock */
- CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video1_clk, "pll-video1",
+ "osc24M", 0x030,
+ 192000000, /* Minimum rate */
+ 8, 7, /* N */
+ 0, 4, /* M */
+ BIT(24), /* frac enable */
+ BIT(25), /* frac select */
+ 270000000, /* frac rate 0 */
+ 297000000, /* frac rate 1 */
+ BIT(31), /* gate */
+ BIT(28), /* lock */
+ CLK_SET_RATE_UNGATE);
static struct ccu_nkm pll_sata_clk = {
.enable = BIT(31),
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
@ 2018-06-13 3:18 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 3:18 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
>
> Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
@ 2018-06-13 3:18 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 3:18 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
>
> Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 01/27] clk: sunxi-ng: r40: Add minimal rate for video PLLs
@ 2018-06-13 3:18 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 3:18 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> According to documentation and experience with other similar SoCs, video
> PLLs don't work stable if their output frequency is set below 192 MHz.
>
> Because of that, set minimal rate to both R40 video PLLs to 192 MHz.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Display related peripherals need precise clocks to operate correctly.
Allow DE2, TCONs and HDMI to set parent clock.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c16a62a7bdbd..fa5317719684 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -655,7 +655,8 @@ static SUNXI_CCU_GATE(dram_deinterlace_clk, "dram-deinterlace", "dram",
static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
- 0x104, 0, 4, 24, 3, BIT(31), 0);
+ 0x104, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mp_clk, "mp", de_parents,
0x108, 0, 4, 24, 3, BIT(31), 0);
@@ -667,9 +668,11 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd0_clk, "tcon-lcd0", tcon_parents,
static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd1_clk, "tcon-lcd1", tcon_parents,
0x114, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv0_clk, "tcon-tv0", tcon_parents,
- 0x118, 0, 4, 24, 3, BIT(31), 0);
+ 0x118, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv1_clk, "tcon-tv1", tcon_parents,
- 0x11c, 0, 4, 24, 3, BIT(31), 0);
+ 0x11c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static const char * const deinterlace_parents[] = { "pll-periph0",
"pll-periph1" };
@@ -699,7 +702,8 @@ static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
static const char * const hdmi_parents[] = { "pll-video0", "pll-video1" };
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
- 0x150, 0, 4, 24, 2, BIT(31), 0);
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_slow_clk, "hdmi-slow", "osc24M",
0x154, BIT(31), 0);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Display related peripherals need precise clocks to operate correctly.
Allow DE2, TCONs and HDMI to set parent clock.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c16a62a7bdbd..fa5317719684 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -655,7 +655,8 @@ static SUNXI_CCU_GATE(dram_deinterlace_clk, "dram-deinterlace", "dram",
static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
- 0x104, 0, 4, 24, 3, BIT(31), 0);
+ 0x104, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mp_clk, "mp", de_parents,
0x108, 0, 4, 24, 3, BIT(31), 0);
@@ -667,9 +668,11 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd0_clk, "tcon-lcd0", tcon_parents,
static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd1_clk, "tcon-lcd1", tcon_parents,
0x114, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv0_clk, "tcon-tv0", tcon_parents,
- 0x118, 0, 4, 24, 3, BIT(31), 0);
+ 0x118, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv1_clk, "tcon-tv1", tcon_parents,
- 0x11c, 0, 4, 24, 3, BIT(31), 0);
+ 0x11c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static const char * const deinterlace_parents[] = { "pll-periph0",
"pll-periph1" };
@@ -699,7 +702,8 @@ static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
static const char * const hdmi_parents[] = { "pll-video0", "pll-video1" };
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
- 0x150, 0, 4, 24, 2, BIT(31), 0);
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_slow_clk, "hdmi-slow", "osc24M",
0x154, BIT(31), 0);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: mark.rutland, devicetree, airlied, gustavo, maarten.lankhorst,
linux-kernel, dri-devel, linux-sunxi, seanpaul, linux-clk,
linux-arm-kernel
Display related peripherals need precise clocks to operate correctly.
Allow DE2, TCONs and HDMI to set parent clock.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c16a62a7bdbd..fa5317719684 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -655,7 +655,8 @@ static SUNXI_CCU_GATE(dram_deinterlace_clk, "dram-deinterlace", "dram",
static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
- 0x104, 0, 4, 24, 3, BIT(31), 0);
+ 0x104, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mp_clk, "mp", de_parents,
0x108, 0, 4, 24, 3, BIT(31), 0);
@@ -667,9 +668,11 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd0_clk, "tcon-lcd0", tcon_parents,
static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd1_clk, "tcon-lcd1", tcon_parents,
0x114, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv0_clk, "tcon-tv0", tcon_parents,
- 0x118, 0, 4, 24, 3, BIT(31), 0);
+ 0x118, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv1_clk, "tcon-tv1", tcon_parents,
- 0x11c, 0, 4, 24, 3, BIT(31), 0);
+ 0x11c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static const char * const deinterlace_parents[] = { "pll-periph0",
"pll-periph1" };
@@ -699,7 +702,8 @@ static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
static const char * const hdmi_parents[] = { "pll-video0", "pll-video1" };
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
- 0x150, 0, 4, 24, 2, BIT(31), 0);
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_slow_clk, "hdmi-slow", "osc24M",
0x154, BIT(31), 0);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Display related peripherals need precise clocks to operate correctly.
Allow DE2, TCONs and HDMI to set parent clock.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
index c16a62a7bdbd..fa5317719684 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
@@ -655,7 +655,8 @@ static SUNXI_CCU_GATE(dram_deinterlace_clk, "dram-deinterlace", "dram",
static const char * const de_parents[] = { "pll-periph0-2x", "pll-de" };
static SUNXI_CCU_M_WITH_MUX_GATE(de_clk, "de", de_parents,
- 0x104, 0, 4, 24, 3, BIT(31), 0);
+ 0x104, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(mp_clk, "mp", de_parents,
0x108, 0, 4, 24, 3, BIT(31), 0);
@@ -667,9 +668,11 @@ static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd0_clk, "tcon-lcd0", tcon_parents,
static SUNXI_CCU_MUX_WITH_GATE(tcon_lcd1_clk, "tcon-lcd1", tcon_parents,
0x114, 24, 3, BIT(31), CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv0_clk, "tcon-tv0", tcon_parents,
- 0x118, 0, 4, 24, 3, BIT(31), 0);
+ 0x118, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_M_WITH_MUX_GATE(tcon_tv1_clk, "tcon-tv1", tcon_parents,
- 0x11c, 0, 4, 24, 3, BIT(31), 0);
+ 0x11c, 0, 4, 24, 3, BIT(31),
+ CLK_SET_RATE_PARENT);
static const char * const deinterlace_parents[] = { "pll-periph0",
"pll-periph1" };
@@ -699,7 +702,8 @@ static SUNXI_CCU_GATE(avs_clk, "avs", "osc24M",
static const char * const hdmi_parents[] = { "pll-video0", "pll-video1" };
static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
- 0x150, 0, 4, 24, 2, BIT(31), 0);
+ 0x150, 0, 4, 24, 2, BIT(31),
+ CLK_SET_RATE_PARENT);
static SUNXI_CCU_GATE(hdmi_slow_clk, "hdmi-slow", "osc24M",
0x154, BIT(31), 0);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
@ 2018-06-13 3:19 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 3:19 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> Display related peripherals need precise clocks to operate correctly.
>
> Allow DE2, TCONs and HDMI to set parent clock.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
@ 2018-06-13 3:19 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 3:19 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> Display related peripherals need precise clocks to operate correctly.
>
> Allow DE2, TCONs and HDMI to set parent clock.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 02/27] clk: sunxi-ng: r40: Allow setting parent rate to display related clocks
@ 2018-06-13 3:19 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 3:19 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Wed, Jun 13, 2018 at 4:00 AM, Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> Display related peripherals need precise clocks to operate correctly.
>
> Allow DE2, TCONs and HDMI to set parent clock.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 03/27] clk: sunxi-ng: r40: Export video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Video PLLs need to be referenced in R40 DT as possible HDMI PHY parent.
Export them.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 ++++++--
include/dt-bindings/clock/sun8i-r40-ccu.h | 4 ++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
index 0db8e1e97af8..db2a1243f9ff 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
@@ -25,7 +25,9 @@
#define CLK_PLL_AUDIO_2X 4
#define CLK_PLL_AUDIO_4X 5
#define CLK_PLL_AUDIO_8X 6
-#define CLK_PLL_VIDEO0 7
+
+/* PLL_VIDEO0 is exported */
+
#define CLK_PLL_VIDEO0_2X 8
#define CLK_PLL_VE 9
#define CLK_PLL_DDR0 10
@@ -34,7 +36,9 @@
#define CLK_PLL_PERIPH0_2X 13
#define CLK_PLL_PERIPH1 14
#define CLK_PLL_PERIPH1_2X 15
-#define CLK_PLL_VIDEO1 16
+
+/* PLL_VIDEO1 is exported */
+
#define CLK_PLL_VIDEO1_2X 17
#define CLK_PLL_SATA 18
#define CLK_PLL_SATA_OUT 19
diff --git a/include/dt-bindings/clock/sun8i-r40-ccu.h b/include/dt-bindings/clock/sun8i-r40-ccu.h
index 4fa5f69fc297..f9e15a235626 100644
--- a/include/dt-bindings/clock/sun8i-r40-ccu.h
+++ b/include/dt-bindings/clock/sun8i-r40-ccu.h
@@ -43,6 +43,10 @@
#ifndef _DT_BINDINGS_CLK_SUN8I_R40_H_
#define _DT_BINDINGS_CLK_SUN8I_R40_H_
+#define CLK_PLL_VIDEO0 7
+
+#define CLK_PLL_VIDEO1 16
+
#define CLK_CPU 24
#define CLK_BUS_MIPI_DSI 29
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 03/27] clk: sunxi-ng: r40: Export video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Video PLLs need to be referenced in R40 DT as possible HDMI PHY parent.
Export them.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 ++++++--
include/dt-bindings/clock/sun8i-r40-ccu.h | 4 ++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
index 0db8e1e97af8..db2a1243f9ff 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
@@ -25,7 +25,9 @@
#define CLK_PLL_AUDIO_2X 4
#define CLK_PLL_AUDIO_4X 5
#define CLK_PLL_AUDIO_8X 6
-#define CLK_PLL_VIDEO0 7
+
+/* PLL_VIDEO0 is exported */
+
#define CLK_PLL_VIDEO0_2X 8
#define CLK_PLL_VE 9
#define CLK_PLL_DDR0 10
@@ -34,7 +36,9 @@
#define CLK_PLL_PERIPH0_2X 13
#define CLK_PLL_PERIPH1 14
#define CLK_PLL_PERIPH1_2X 15
-#define CLK_PLL_VIDEO1 16
+
+/* PLL_VIDEO1 is exported */
+
#define CLK_PLL_VIDEO1_2X 17
#define CLK_PLL_SATA 18
#define CLK_PLL_SATA_OUT 19
diff --git a/include/dt-bindings/clock/sun8i-r40-ccu.h b/include/dt-bindings/clock/sun8i-r40-ccu.h
index 4fa5f69fc297..f9e15a235626 100644
--- a/include/dt-bindings/clock/sun8i-r40-ccu.h
+++ b/include/dt-bindings/clock/sun8i-r40-ccu.h
@@ -43,6 +43,10 @@
#ifndef _DT_BINDINGS_CLK_SUN8I_R40_H_
#define _DT_BINDINGS_CLK_SUN8I_R40_H_
+#define CLK_PLL_VIDEO0 7
+
+#define CLK_PLL_VIDEO1 16
+
#define CLK_CPU 24
#define CLK_BUS_MIPI_DSI 29
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 03/27] clk: sunxi-ng: r40: Export video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: mark.rutland, devicetree, airlied, gustavo, maarten.lankhorst,
linux-kernel, dri-devel, linux-sunxi, seanpaul, linux-clk,
linux-arm-kernel
Video PLLs need to be referenced in R40 DT as possible HDMI PHY parent.
Export them.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 ++++++--
include/dt-bindings/clock/sun8i-r40-ccu.h | 4 ++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
index 0db8e1e97af8..db2a1243f9ff 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
@@ -25,7 +25,9 @@
#define CLK_PLL_AUDIO_2X 4
#define CLK_PLL_AUDIO_4X 5
#define CLK_PLL_AUDIO_8X 6
-#define CLK_PLL_VIDEO0 7
+
+/* PLL_VIDEO0 is exported */
+
#define CLK_PLL_VIDEO0_2X 8
#define CLK_PLL_VE 9
#define CLK_PLL_DDR0 10
@@ -34,7 +36,9 @@
#define CLK_PLL_PERIPH0_2X 13
#define CLK_PLL_PERIPH1 14
#define CLK_PLL_PERIPH1_2X 15
-#define CLK_PLL_VIDEO1 16
+
+/* PLL_VIDEO1 is exported */
+
#define CLK_PLL_VIDEO1_2X 17
#define CLK_PLL_SATA 18
#define CLK_PLL_SATA_OUT 19
diff --git a/include/dt-bindings/clock/sun8i-r40-ccu.h b/include/dt-bindings/clock/sun8i-r40-ccu.h
index 4fa5f69fc297..f9e15a235626 100644
--- a/include/dt-bindings/clock/sun8i-r40-ccu.h
+++ b/include/dt-bindings/clock/sun8i-r40-ccu.h
@@ -43,6 +43,10 @@
#ifndef _DT_BINDINGS_CLK_SUN8I_R40_H_
#define _DT_BINDINGS_CLK_SUN8I_R40_H_
+#define CLK_PLL_VIDEO0 7
+
+#define CLK_PLL_VIDEO1 16
+
#define CLK_CPU 24
#define CLK_BUS_MIPI_DSI 29
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 03/27] clk: sunxi-ng: r40: Export video PLLs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Video PLLs need to be referenced in R40 DT as possible HDMI PHY parent.
Export them.
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/clk/sunxi-ng/ccu-sun8i-r40.h | 8 ++++++--
include/dt-bindings/clock/sun8i-r40-ccu.h | 4 ++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
index 0db8e1e97af8..db2a1243f9ff 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.h
@@ -25,7 +25,9 @@
#define CLK_PLL_AUDIO_2X 4
#define CLK_PLL_AUDIO_4X 5
#define CLK_PLL_AUDIO_8X 6
-#define CLK_PLL_VIDEO0 7
+
+/* PLL_VIDEO0 is exported */
+
#define CLK_PLL_VIDEO0_2X 8
#define CLK_PLL_VE 9
#define CLK_PLL_DDR0 10
@@ -34,7 +36,9 @@
#define CLK_PLL_PERIPH0_2X 13
#define CLK_PLL_PERIPH1 14
#define CLK_PLL_PERIPH1_2X 15
-#define CLK_PLL_VIDEO1 16
+
+/* PLL_VIDEO1 is exported */
+
#define CLK_PLL_VIDEO1_2X 17
#define CLK_PLL_SATA 18
#define CLK_PLL_SATA_OUT 19
diff --git a/include/dt-bindings/clock/sun8i-r40-ccu.h b/include/dt-bindings/clock/sun8i-r40-ccu.h
index 4fa5f69fc297..f9e15a235626 100644
--- a/include/dt-bindings/clock/sun8i-r40-ccu.h
+++ b/include/dt-bindings/clock/sun8i-r40-ccu.h
@@ -43,6 +43,10 @@
#ifndef _DT_BINDINGS_CLK_SUN8I_R40_H_
#define _DT_BINDINGS_CLK_SUN8I_R40_H_
+#define CLK_PLL_VIDEO0 7
+
+#define CLK_PLL_VIDEO1 16
+
#define CLK_CPU 24
#define CLK_BUS_MIPI_DSI 29
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
TCON TOP main purpose is to configure whole display pipeline. It
determines relationships between mixers and TCONs, selects source TCON
for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
clock source and contains additional TV TCON and DSI gates.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
2 files changed, 56 insertions(+)
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 3346c1e2a7a0..ef64c589a4b3 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
- 'lvds-alt': An alternative clock source, separate from the TCON channel 0
clock, that can be used to drive the LVDS clock
+TCON TOP
+--------
+
+TCON TOPs main purpose is to configure whole display pipeline. It determines
+relationships between mixers and TCONs, selects source TCON for HDMI, muxes
+LCD and TV encoder GPIO output, selects TV encoder clock source and contains
+additional TV TCON and DSI gates.
+
+It allows display pipeline to be configured in very different ways:
+
+ / LCD0/LVDS0
+ / TCON-LCD0
+ | \ MIPI DSI
+ mixer0 |
+ \ / TCON-LCD1 - LCD1/LVDS1
+ TCON-TOP
+ / \ TCON-TV0 - TVE0/RGB
+ mixer1 | \
+ | TCON-TOP - HDMI
+ | /
+ \ TCON-TV1 - TVE1/RGB
+
+Note that both TCON TOP references same physical unit.
+
+Required properties:
+ - compatible: value must be one of:
+ * allwinner,sun8i-r40-tcon-top
+ - reg: base address and size of the memory-mapped region.
+ - clocks: phandle to the clocks feeding the TCON TOP
+ * bus: TCON TOP interface clock
+ - clock-names: clock name mentioned above
+ - resets: phandle to the reset line driving the DRC
+ * rst: TCON TOP reset line
+ - reset-names: reset name mentioned above
+ - #clock-cells : must contain 1
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
+ should be the input for mixer0 mux. The second should be the output for that
+ mux. Third port should be input for mixer1 mux. Fourth port should be output
+ for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
+ be output for it. All output endpoints should have reg property with the id
+ of the target TCON. All ports should have only one enpoint connected to
+ remote endpoint.
+
DRC
---
diff --git a/include/dt-bindings/clock/sun8i-tcon-top.h b/include/dt-bindings/clock/sun8i-tcon-top.h
new file mode 100644
index 000000000000..c05e92770402
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-tcon-top.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/* Copyright (C) 2018 Jernej Skrabec <jernej.skrabec@siol.net> */
+
+#ifndef _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+#define _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+
+#define CLK_BUS_TCON_TOP_DSI 0
+#define CLK_BUS_TCON_TOP_TV0 1
+#define CLK_BUS_TCON_TOP_TV1 2
+
+#endif /* _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ */
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
TCON TOP main purpose is to configure whole display pipeline. It
determines relationships between mixers and TCONs, selects source TCON
for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
clock source and contains additional TV TCON and DSI gates.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
2 files changed, 56 insertions(+)
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 3346c1e2a7a0..ef64c589a4b3 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
- 'lvds-alt': An alternative clock source, separate from the TCON channel 0
clock, that can be used to drive the LVDS clock
+TCON TOP
+--------
+
+TCON TOPs main purpose is to configure whole display pipeline. It determines
+relationships between mixers and TCONs, selects source TCON for HDMI, muxes
+LCD and TV encoder GPIO output, selects TV encoder clock source and contains
+additional TV TCON and DSI gates.
+
+It allows display pipeline to be configured in very different ways:
+
+ / LCD0/LVDS0
+ / TCON-LCD0
+ | \ MIPI DSI
+ mixer0 |
+ \ / TCON-LCD1 - LCD1/LVDS1
+ TCON-TOP
+ / \ TCON-TV0 - TVE0/RGB
+ mixer1 | \
+ | TCON-TOP - HDMI
+ | /
+ \ TCON-TV1 - TVE1/RGB
+
+Note that both TCON TOP references same physical unit.
+
+Required properties:
+ - compatible: value must be one of:
+ * allwinner,sun8i-r40-tcon-top
+ - reg: base address and size of the memory-mapped region.
+ - clocks: phandle to the clocks feeding the TCON TOP
+ * bus: TCON TOP interface clock
+ - clock-names: clock name mentioned above
+ - resets: phandle to the reset line driving the DRC
+ * rst: TCON TOP reset line
+ - reset-names: reset name mentioned above
+ - #clock-cells : must contain 1
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
+ should be the input for mixer0 mux. The second should be the output for that
+ mux. Third port should be input for mixer1 mux. Fourth port should be output
+ for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
+ be output for it. All output endpoints should have reg property with the id
+ of the target TCON. All ports should have only one enpoint connected to
+ remote endpoint.
+
DRC
---
diff --git a/include/dt-bindings/clock/sun8i-tcon-top.h b/include/dt-bindings/clock/sun8i-tcon-top.h
new file mode 100644
index 000000000000..c05e92770402
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-tcon-top.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/* Copyright (C) 2018 Jernej Skrabec <jernej.skrabec@siol.net> */
+
+#ifndef _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+#define _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+
+#define CLK_BUS_TCON_TOP_DSI 0
+#define CLK_BUS_TCON_TOP_TV0 1
+#define CLK_BUS_TCON_TOP_TV1 2
+
+#endif /* _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ */
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: mark.rutland, devicetree, airlied, gustavo, maarten.lankhorst,
linux-kernel, dri-devel, linux-sunxi, seanpaul, linux-clk,
linux-arm-kernel
TCON TOP main purpose is to configure whole display pipeline. It
determines relationships between mixers and TCONs, selects source TCON
for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
clock source and contains additional TV TCON and DSI gates.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
2 files changed, 56 insertions(+)
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 3346c1e2a7a0..ef64c589a4b3 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
- 'lvds-alt': An alternative clock source, separate from the TCON channel 0
clock, that can be used to drive the LVDS clock
+TCON TOP
+--------
+
+TCON TOPs main purpose is to configure whole display pipeline. It determines
+relationships between mixers and TCONs, selects source TCON for HDMI, muxes
+LCD and TV encoder GPIO output, selects TV encoder clock source and contains
+additional TV TCON and DSI gates.
+
+It allows display pipeline to be configured in very different ways:
+
+ / LCD0/LVDS0
+ / TCON-LCD0
+ | \ MIPI DSI
+ mixer0 |
+ \ / TCON-LCD1 - LCD1/LVDS1
+ TCON-TOP
+ / \ TCON-TV0 - TVE0/RGB
+ mixer1 | \
+ | TCON-TOP - HDMI
+ | /
+ \ TCON-TV1 - TVE1/RGB
+
+Note that both TCON TOP references same physical unit.
+
+Required properties:
+ - compatible: value must be one of:
+ * allwinner,sun8i-r40-tcon-top
+ - reg: base address and size of the memory-mapped region.
+ - clocks: phandle to the clocks feeding the TCON TOP
+ * bus: TCON TOP interface clock
+ - clock-names: clock name mentioned above
+ - resets: phandle to the reset line driving the DRC
+ * rst: TCON TOP reset line
+ - reset-names: reset name mentioned above
+ - #clock-cells : must contain 1
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
+ should be the input for mixer0 mux. The second should be the output for that
+ mux. Third port should be input for mixer1 mux. Fourth port should be output
+ for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
+ be output for it. All output endpoints should have reg property with the id
+ of the target TCON. All ports should have only one enpoint connected to
+ remote endpoint.
+
DRC
---
diff --git a/include/dt-bindings/clock/sun8i-tcon-top.h b/include/dt-bindings/clock/sun8i-tcon-top.h
new file mode 100644
index 000000000000..c05e92770402
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-tcon-top.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/* Copyright (C) 2018 Jernej Skrabec <jernej.skrabec@siol.net> */
+
+#ifndef _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+#define _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+
+#define CLK_BUS_TCON_TOP_DSI 0
+#define CLK_BUS_TCON_TOP_TV0 1
+#define CLK_BUS_TCON_TOP_TV1 2
+
+#endif /* _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
TCON TOP main purpose is to configure whole display pipeline. It
determines relationships between mixers and TCONs, selects source TCON
for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
clock source and contains additional TV TCON and DSI gates.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
.../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
2 files changed, 56 insertions(+)
create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 3346c1e2a7a0..ef64c589a4b3 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
- 'lvds-alt': An alternative clock source, separate from the TCON channel 0
clock, that can be used to drive the LVDS clock
+TCON TOP
+--------
+
+TCON TOPs main purpose is to configure whole display pipeline. It determines
+relationships between mixers and TCONs, selects source TCON for HDMI, muxes
+LCD and TV encoder GPIO output, selects TV encoder clock source and contains
+additional TV TCON and DSI gates.
+
+It allows display pipeline to be configured in very different ways:
+
+ / LCD0/LVDS0
+ / TCON-LCD0
+ | \ MIPI DSI
+ mixer0 |
+ \ / TCON-LCD1 - LCD1/LVDS1
+ TCON-TOP
+ / \ TCON-TV0 - TVE0/RGB
+ mixer1 | \
+ | TCON-TOP - HDMI
+ | /
+ \ TCON-TV1 - TVE1/RGB
+
+Note that both TCON TOP references same physical unit.
+
+Required properties:
+ - compatible: value must be one of:
+ * allwinner,sun8i-r40-tcon-top
+ - reg: base address and size of the memory-mapped region.
+ - clocks: phandle to the clocks feeding the TCON TOP
+ * bus: TCON TOP interface clock
+ - clock-names: clock name mentioned above
+ - resets: phandle to the reset line driving the DRC
+ * rst: TCON TOP reset line
+ - reset-names: reset name mentioned above
+ - #clock-cells : must contain 1
+
+- ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
+ should be the input for mixer0 mux. The second should be the output for that
+ mux. Third port should be input for mixer1 mux. Fourth port should be output
+ for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
+ be output for it. All output endpoints should have reg property with the id
+ of the target TCON. All ports should have only one enpoint connected to
+ remote endpoint.
+
DRC
---
diff --git a/include/dt-bindings/clock/sun8i-tcon-top.h b/include/dt-bindings/clock/sun8i-tcon-top.h
new file mode 100644
index 000000000000..c05e92770402
--- /dev/null
+++ b/include/dt-bindings/clock/sun8i-tcon-top.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0+ OR MIT) */
+/* Copyright (C) 2018 Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> */
+
+#ifndef _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+#define _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_
+
+#define CLK_BUS_TCON_TOP_DSI 0
+#define CLK_BUS_TCON_TOP_TV0 1
+#define CLK_BUS_TCON_TOP_TV1 2
+
+#endif /* _DT_BINDINGS_CLOCK_SUN8I_TCON_TOP_H_ */
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-13 7:34 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:34 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens, robh+dt, airlied, gustavo, maarten.lankhorst, seanpaul,
mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]
Hi,
Thanks for working on this!
On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> TCON TOP main purpose is to configure whole display pipeline. It
> determines relationships between mixers and TCONs, selects source TCON
> for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
> clock source and contains additional TV TCON and DSI gates.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
> include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
> 2 files changed, 56 insertions(+)
> create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 3346c1e2a7a0..ef64c589a4b3 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
> - 'lvds-alt': An alternative clock source, separate from the TCON channel 0
> clock, that can be used to drive the LVDS clock
>
> +TCON TOP
> +--------
> +
> +TCON TOPs main purpose is to configure whole display pipeline. It determines
> +relationships between mixers and TCONs, selects source TCON for HDMI, muxes
> +LCD and TV encoder GPIO output, selects TV encoder clock source and contains
> +additional TV TCON and DSI gates.
> +
> +It allows display pipeline to be configured in very different ways:
> +
> + / LCD0/LVDS0
> + / TCON-LCD0
> + | \ MIPI DSI
> + mixer0 |
> + \ / TCON-LCD1 - LCD1/LVDS1
> + TCON-TOP
> + / \ TCON-TV0 - TVE0/RGB
> + mixer1 | \
> + | TCON-TOP - HDMI
> + | /
> + \ TCON-TV1 - TVE1/RGB
> +
> +Note that both TCON TOP references same physical unit.
> +
> +Required properties:
> + - compatible: value must be one of:
> + * allwinner,sun8i-r40-tcon-top
> + - reg: base address and size of the memory-mapped region.
> + - clocks: phandle to the clocks feeding the TCON TOP
> + * bus: TCON TOP interface clock
> + - clock-names: clock name mentioned above
> + - resets: phandle to the reset line driving the DRC
s/DRC/TCON TOP/ ?
> + * rst: TCON TOP reset line
Remaining consistent with the clock name would be great
> + - reset-names: reset name mentioned above
> + - #clock-cells : must contain 1
An example would be nice here
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
> + should be the input for mixer0 mux. The second should be the output for that
> + mux. Third port should be input for mixer1 mux. Fourth port should be output
> + for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
> + be output for it. All output endpoints should have reg property with the id
> + of the target TCON. All ports should have only one enpoint connected to
^ endpoint
I guess it would me more readable if you were to make it a bullet
list, but this works for me otherwise.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-13 7:34 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Thanks for working on this!
On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> TCON TOP main purpose is to configure whole display pipeline. It
> determines relationships between mixers and TCONs, selects source TCON
> for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
> clock source and contains additional TV TCON and DSI gates.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
> include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
> 2 files changed, 56 insertions(+)
> create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 3346c1e2a7a0..ef64c589a4b3 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
> - 'lvds-alt': An alternative clock source, separate from the TCON channel 0
> clock, that can be used to drive the LVDS clock
>
> +TCON TOP
> +--------
> +
> +TCON TOPs main purpose is to configure whole display pipeline. It determines
> +relationships between mixers and TCONs, selects source TCON for HDMI, muxes
> +LCD and TV encoder GPIO output, selects TV encoder clock source and contains
> +additional TV TCON and DSI gates.
> +
> +It allows display pipeline to be configured in very different ways:
> +
> + / LCD0/LVDS0
> + / TCON-LCD0
> + | \ MIPI DSI
> + mixer0 |
> + \ / TCON-LCD1 - LCD1/LVDS1
> + TCON-TOP
> + / \ TCON-TV0 - TVE0/RGB
> + mixer1 | \
> + | TCON-TOP - HDMI
> + | /
> + \ TCON-TV1 - TVE1/RGB
> +
> +Note that both TCON TOP references same physical unit.
> +
> +Required properties:
> + - compatible: value must be one of:
> + * allwinner,sun8i-r40-tcon-top
> + - reg: base address and size of the memory-mapped region.
> + - clocks: phandle to the clocks feeding the TCON TOP
> + * bus: TCON TOP interface clock
> + - clock-names: clock name mentioned above
> + - resets: phandle to the reset line driving the DRC
s/DRC/TCON TOP/ ?
> + * rst: TCON TOP reset line
Remaining consistent with the clock name would be great
> + - reset-names: reset name mentioned above
> + - #clock-cells : must contain 1
An example would be nice here
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
> + should be the input for mixer0 mux. The second should be the output for that
> + mux. Third port should be input for mixer1 mux. Fourth port should be output
> + for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
> + be output for it. All output endpoints should have reg property with the id
> + of the target TCON. All ports should have only one enpoint connected to
^ endpoint
I guess it would me more readable if you were to make it a bullet
list, but this works for me otherwise.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/22350a8e/attachment.sig>
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-13 7:34 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:34 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 3574 bytes --]
Hi,
Thanks for working on this!
On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> TCON TOP main purpose is to configure whole display pipeline. It
> determines relationships between mixers and TCONs, selects source TCON
> for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
> clock source and contains additional TV TCON and DSI gates.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> .../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
> include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
> 2 files changed, 56 insertions(+)
> create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index 3346c1e2a7a0..ef64c589a4b3 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more clock line:
> - 'lvds-alt': An alternative clock source, separate from the TCON channel 0
> clock, that can be used to drive the LVDS clock
>
> +TCON TOP
> +--------
> +
> +TCON TOPs main purpose is to configure whole display pipeline. It determines
> +relationships between mixers and TCONs, selects source TCON for HDMI, muxes
> +LCD and TV encoder GPIO output, selects TV encoder clock source and contains
> +additional TV TCON and DSI gates.
> +
> +It allows display pipeline to be configured in very different ways:
> +
> + / LCD0/LVDS0
> + / TCON-LCD0
> + | \ MIPI DSI
> + mixer0 |
> + \ / TCON-LCD1 - LCD1/LVDS1
> + TCON-TOP
> + / \ TCON-TV0 - TVE0/RGB
> + mixer1 | \
> + | TCON-TOP - HDMI
> + | /
> + \ TCON-TV1 - TVE1/RGB
> +
> +Note that both TCON TOP references same physical unit.
> +
> +Required properties:
> + - compatible: value must be one of:
> + * allwinner,sun8i-r40-tcon-top
> + - reg: base address and size of the memory-mapped region.
> + - clocks: phandle to the clocks feeding the TCON TOP
> + * bus: TCON TOP interface clock
> + - clock-names: clock name mentioned above
> + - resets: phandle to the reset line driving the DRC
s/DRC/TCON TOP/ ?
> + * rst: TCON TOP reset line
Remaining consistent with the clock name would be great
> + - reset-names: reset name mentioned above
> + - #clock-cells : must contain 1
An example would be nice here
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt. The first port
> + should be the input for mixer0 mux. The second should be the output for that
> + mux. Third port should be input for mixer1 mux. Fourth port should be output
> + for mixer1 mux. Fifth port should be input for HDMI mux. Sixth port should
> + be output for it. All output endpoints should have reg property with the id
> + of the target TCON. All ports should have only one enpoint connected to
^ endpoint
I guess it would me more readable if you were to make it a bullet
list, but this works for me otherwise.
Thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
2018-06-13 7:34 ` Maxime Ripard
(?)
@ 2018-06-13 16:03 ` Jernej Škrabec
-1 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:03 UTC (permalink / raw)
To: linux-sunxi, maxime.ripard
Cc: wens, robh+dt, airlied, gustavo, maarten.lankhorst, seanpaul,
mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk
Hi,
Dne sreda, 13. junij 2018 ob 09:34:56 CEST je Maxime Ripard napisal(a):
> Hi,
>
> Thanks for working on this!
>
> On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> > TCON TOP main purpose is to configure whole display pipeline. It
> > determines relationships between mixers and TCONs, selects source TCON
> > for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
> > clock source and contains additional TV TCON and DSI gates.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > .../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
> > include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
> > 2 files changed, 56 insertions(+)
> > create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > 3346c1e2a7a0..ef64c589a4b3 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> >
> > @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more
clock line:
> > - 'lvds-alt': An alternative clock source, separate from the TCON
> > channel 0
> >
> > clock, that can be used to drive the LVDS clock
> >
> > +TCON TOP
> > +--------
> > +
> > +TCON TOPs main purpose is to configure whole display pipeline. It
> > determines +relationships between mixers and TCONs, selects source TCON
> > for HDMI, muxes +LCD and TV encoder GPIO output, selects TV encoder clock
> > source and contains +additional TV TCON and DSI gates.
> > +
> > +It allows display pipeline to be configured in very different ways:
> > +
> > + / LCD0/LVDS0
> > + / TCON-LCD0
> > + | \ MIPI DSI
> > + mixer0 |
> > + \ / TCON-LCD1 - LCD1/LVDS1
> > + TCON-TOP
> > + / \ TCON-TV0 - TVE0/RGB
> > + mixer1 | \
> > + | TCON-TOP - HDMI
> > + | /
> > + \ TCON-TV1 - TVE1/RGB
> > +
> > +Note that both TCON TOP references same physical unit.
> > +
> > +Required properties:
> > + - compatible: value must be one of:
> > + * allwinner,sun8i-r40-tcon-top
> > + - reg: base address and size of the memory-mapped region.
> > + - clocks: phandle to the clocks feeding the TCON TOP
> > + * bus: TCON TOP interface clock
> > + - clock-names: clock name mentioned above
> > + - resets: phandle to the reset line driving the DRC
>
> s/DRC/TCON TOP/ ?
Yes, copy & paste issue
>
> > + * rst: TCON TOP reset line
>
> Remaining consistent with the clock name would be great
You mean "ahb"? I noticed that most other nodes with reset lines don't have a
name associated. Maybe I could just drop it and use first specified reset?
>
> > + - reset-names: reset name mentioned above
> > + - #clock-cells : must contain 1
>
> An example would be nice here
You mean node example? with ports? In the past, Rob was against examples
unless really necessary. Node from R40 DTSI can serve as an example.
>
> > +- ports: A ports node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > first port + should be the input for mixer0 mux. The second should be
> > the output for that + mux. Third port should be input for mixer1 mux.
> > Fourth port should be output + for mixer1 mux. Fifth port should be
> > input for HDMI mux. Sixth port should + be output for it. All output
> > endpoints should have reg property with the id + of the target TCON.
> > All ports should have only one enpoint connected to
> ^ endpoint
>
> I guess it would me more readable if you were to make it a bullet
> list, but this works for me otherwise.
Since I have to fix this patch anyway, I can refactor this text.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-13 16:03 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Dne sreda, 13. junij 2018 ob 09:34:56 CEST je Maxime Ripard napisal(a):
> Hi,
>
> Thanks for working on this!
>
> On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> > TCON TOP main purpose is to configure whole display pipeline. It
> > determines relationships between mixers and TCONs, selects source TCON
> > for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
> > clock source and contains additional TV TCON and DSI gates.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > .../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
> > include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
> > 2 files changed, 56 insertions(+)
> > create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > 3346c1e2a7a0..ef64c589a4b3 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> >
> > @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more
clock line:
> > - 'lvds-alt': An alternative clock source, separate from the TCON
> > channel 0
> >
> > clock, that can be used to drive the LVDS clock
> >
> > +TCON TOP
> > +--------
> > +
> > +TCON TOPs main purpose is to configure whole display pipeline. It
> > determines +relationships between mixers and TCONs, selects source TCON
> > for HDMI, muxes +LCD and TV encoder GPIO output, selects TV encoder clock
> > source and contains +additional TV TCON and DSI gates.
> > +
> > +It allows display pipeline to be configured in very different ways:
> > +
> > + / LCD0/LVDS0
> > + / TCON-LCD0
> > + | \ MIPI DSI
> > + mixer0 |
> > + \ / TCON-LCD1 - LCD1/LVDS1
> > + TCON-TOP
> > + / \ TCON-TV0 - TVE0/RGB
> > + mixer1 | \
> > + | TCON-TOP - HDMI
> > + | /
> > + \ TCON-TV1 - TVE1/RGB
> > +
> > +Note that both TCON TOP references same physical unit.
> > +
> > +Required properties:
> > + - compatible: value must be one of:
> > + * allwinner,sun8i-r40-tcon-top
> > + - reg: base address and size of the memory-mapped region.
> > + - clocks: phandle to the clocks feeding the TCON TOP
> > + * bus: TCON TOP interface clock
> > + - clock-names: clock name mentioned above
> > + - resets: phandle to the reset line driving the DRC
>
> s/DRC/TCON TOP/ ?
Yes, copy & paste issue
>
> > + * rst: TCON TOP reset line
>
> Remaining consistent with the clock name would be great
You mean "ahb"? I noticed that most other nodes with reset lines don't have a
name associated. Maybe I could just drop it and use first specified reset?
>
> > + - reset-names: reset name mentioned above
> > + - #clock-cells : must contain 1
>
> An example would be nice here
You mean node example? with ports? In the past, Rob was against examples
unless really necessary. Node from R40 DTSI can serve as an example.
>
> > +- ports: A ports node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > first port + should be the input for mixer0 mux. The second should be
> > the output for that + mux. Third port should be input for mixer1 mux.
> > Fourth port should be output + for mixer1 mux. Fifth port should be
> > input for HDMI mux. Sixth port should + be output for it. All output
> > endpoints should have reg property with the id + of the target TCON.
> > All ports should have only one enpoint connected to
> ^ endpoint
>
> I guess it would me more readable if you were to make it a bullet
> list, but this works for me otherwise.
Since I have to fix this patch anyway, I can refactor this text.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-13 16:03 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:03 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA
Hi,
Dne sreda, 13. junij 2018 ob 09:34:56 CEST je Maxime Ripard napisal(a):
> Hi,
>
> Thanks for working on this!
>
> On Tue, Jun 12, 2018 at 10:00:13PM +0200, Jernej Skrabec wrote:
> > TCON TOP main purpose is to configure whole display pipeline. It
> > determines relationships between mixers and TCONs, selects source TCON
> > for HDMI, muxes LCD and TV encoder GPIO output, selects TV encoder
> > clock source and contains additional TV TCON and DSI gates.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> > ---
> >
> > .../bindings/display/sunxi/sun4i-drm.txt | 45 +++++++++++++++++++
> > include/dt-bindings/clock/sun8i-tcon-top.h | 11 +++++
> > 2 files changed, 56 insertions(+)
> > create mode 100644 include/dt-bindings/clock/sun8i-tcon-top.h
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > 3346c1e2a7a0..ef64c589a4b3 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> >
> > @@ -187,6 +187,51 @@ And on the A23, A31, A31s and A33, you need one more
clock line:
> > - 'lvds-alt': An alternative clock source, separate from the TCON
> > channel 0
> >
> > clock, that can be used to drive the LVDS clock
> >
> > +TCON TOP
> > +--------
> > +
> > +TCON TOPs main purpose is to configure whole display pipeline. It
> > determines +relationships between mixers and TCONs, selects source TCON
> > for HDMI, muxes +LCD and TV encoder GPIO output, selects TV encoder clock
> > source and contains +additional TV TCON and DSI gates.
> > +
> > +It allows display pipeline to be configured in very different ways:
> > +
> > + / LCD0/LVDS0
> > + / TCON-LCD0
> > + | \ MIPI DSI
> > + mixer0 |
> > + \ / TCON-LCD1 - LCD1/LVDS1
> > + TCON-TOP
> > + / \ TCON-TV0 - TVE0/RGB
> > + mixer1 | \
> > + | TCON-TOP - HDMI
> > + | /
> > + \ TCON-TV1 - TVE1/RGB
> > +
> > +Note that both TCON TOP references same physical unit.
> > +
> > +Required properties:
> > + - compatible: value must be one of:
> > + * allwinner,sun8i-r40-tcon-top
> > + - reg: base address and size of the memory-mapped region.
> > + - clocks: phandle to the clocks feeding the TCON TOP
> > + * bus: TCON TOP interface clock
> > + - clock-names: clock name mentioned above
> > + - resets: phandle to the reset line driving the DRC
>
> s/DRC/TCON TOP/ ?
Yes, copy & paste issue
>
> > + * rst: TCON TOP reset line
>
> Remaining consistent with the clock name would be great
You mean "ahb"? I noticed that most other nodes with reset lines don't have a
name associated. Maybe I could just drop it and use first specified reset?
>
> > + - reset-names: reset name mentioned above
> > + - #clock-cells : must contain 1
>
> An example would be nice here
You mean node example? with ports? In the past, Rob was against examples
unless really necessary. Node from R40 DTSI can serve as an example.
>
> > +- ports: A ports node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > first port + should be the input for mixer0 mux. The second should be
> > the output for that + mux. Third port should be input for mixer1 mux.
> > Fourth port should be output + for mixer1 mux. Fifth port should be
> > input for HDMI mux. Sixth port should + be output for it. All output
> > endpoints should have reg property with the id + of the target TCON.
> > All ports should have only one enpoint connected to
> ^ endpoint
>
> I guess it would me more readable if you were to make it a bullet
> list, but this works for me otherwise.
Since I have to fix this patch anyway, I can refactor this text.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
2018-06-13 16:03 ` Jernej Škrabec
(?)
@ 2018-06-15 8:45 ` Maxime Ripard
-1 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-15 8:45 UTC (permalink / raw)
To: Jernej Škrabec
Cc: linux-sunxi, wens, robh+dt, airlied, gustavo, maarten.lankhorst,
seanpaul, mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk
[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]
On Wed, Jun 13, 2018 at 06:03:21PM +0200, Jernej Škrabec wrote:
> > > +Required properties:
> > > + - compatible: value must be one of:
> > > + * allwinner,sun8i-r40-tcon-top
> > > + - reg: base address and size of the memory-mapped region.
> > > + - clocks: phandle to the clocks feeding the TCON TOP
> > > + * bus: TCON TOP interface clock
> > > + - clock-names: clock name mentioned above
> > > + - resets: phandle to the reset line driving the DRC
> >
> > s/DRC/TCON TOP/ ?
>
> Yes, copy & paste issue
>
> >
> > > + * rst: TCON TOP reset line
> >
> > Remaining consistent with the clock name would be great
>
> You mean "ahb"? I noticed that most other nodes with reset lines don't have a
> name associated. Maybe I could just drop it and use first specified reset?
It's called bus in the binding, but yes. And yeah, we can drop the
name as well.
> >
> > > + - reset-names: reset name mentioned above
> > > + - #clock-cells : must contain 1
> >
> > An example would be nice here
>
> You mean node example? with ports? In the past, Rob was against examples
> unless really necessary. Node from R40 DTSI can serve as an example.
Ok.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-15 8:45 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-15 8:45 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 13, 2018 at 06:03:21PM +0200, Jernej ?krabec wrote:
> > > +Required properties:
> > > + - compatible: value must be one of:
> > > + * allwinner,sun8i-r40-tcon-top
> > > + - reg: base address and size of the memory-mapped region.
> > > + - clocks: phandle to the clocks feeding the TCON TOP
> > > + * bus: TCON TOP interface clock
> > > + - clock-names: clock name mentioned above
> > > + - resets: phandle to the reset line driving the DRC
> >
> > s/DRC/TCON TOP/ ?
>
> Yes, copy & paste issue
>
> >
> > > + * rst: TCON TOP reset line
> >
> > Remaining consistent with the clock name would be great
>
> You mean "ahb"? I noticed that most other nodes with reset lines don't have a
> name associated. Maybe I could just drop it and use first specified reset?
It's called bus in the binding, but yes. And yeah, we can drop the
name as well.
> >
> > > + - reset-names: reset name mentioned above
> > > + - #clock-cells : must contain 1
> >
> > An example would be nice here
>
> You mean node example? with ports? In the past, Rob was against examples
> unless really necessary. Node from R40 DTSI can serve as an example.
Ok.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/6770fcf3/attachment.sig>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] Re: [PATCH v2 04/27] dt-bindings: display: sunxi-drm: Add TCON TOP description
@ 2018-06-15 8:45 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-15 8:45 UTC (permalink / raw)
To: Jernej Škrabec
Cc: mark.rutland, devicetree, airlied, wens, dri-devel, linux-kernel,
linux-sunxi, robh+dt, linux-clk, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1328 bytes --]
On Wed, Jun 13, 2018 at 06:03:21PM +0200, Jernej Škrabec wrote:
> > > +Required properties:
> > > + - compatible: value must be one of:
> > > + * allwinner,sun8i-r40-tcon-top
> > > + - reg: base address and size of the memory-mapped region.
> > > + - clocks: phandle to the clocks feeding the TCON TOP
> > > + * bus: TCON TOP interface clock
> > > + - clock-names: clock name mentioned above
> > > + - resets: phandle to the reset line driving the DRC
> >
> > s/DRC/TCON TOP/ ?
>
> Yes, copy & paste issue
>
> >
> > > + * rst: TCON TOP reset line
> >
> > Remaining consistent with the clock name would be great
>
> You mean "ahb"? I noticed that most other nodes with reset lines don't have a
> name associated. Maybe I could just drop it and use first specified reset?
It's called bus in the binding, but yes. And yeah, we can drop the
name as well.
> >
> > > + - reset-names: reset name mentioned above
> > > + - #clock-cells : must contain 1
> >
> > An example would be nice here
>
> You mean node example? with ports? In the past, Rob was against examples
> unless really necessary. Node from R40 DTSI can serve as an example.
Ok.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 05/27] drm/sun4i: Add TCON TOP driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
As already described in DT binding, TCON TOP is responsible for
configuring display pipeline. In this initial driver focus is on HDMI
pipeline, so TVE and LCD configuration is not implemented.
Implemented features:
- HDMI source selection
- clock driver (TCON and DSI gating)
- connecting mixers and TCONS
Something similar also existed in previous SoCs, except that it was part
of first TCON.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 248 +++++++++++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 38 ++++
3 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2589f4acd5ae..09fbfd6304ba 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -16,7 +16,8 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
- sun8i_vi_scaler.o sun8i_csc.o
+ sun8i_vi_scaler.o sun8i_csc.o \
+ sun8i_tcon_top.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
new file mode 100644
index 000000000000..60b17e893f08
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2018 Jernej Skrabec <jernej.skrabec@siol.net> */
+
+#include <drm/drmP.h>
+
+#include <dt-bindings/clock/sun8i-tcon-top.h>
+
+#include <linux/bitfield.h>
+#include <linux/component.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+
+#include "sun8i_tcon_top.h"
+
+struct sun8i_tcon_top_gate {
+ const char *name;
+ u8 bit;
+ int index;
+};
+
+static const struct sun8i_tcon_top_gate gates[] = {
+ {"bus-tcon-top-dsi", TCON_TOP_TCON_DSI_GATE, CLK_BUS_TCON_TOP_DSI},
+ {"bus-tcon-top-tv0", TCON_TOP_TCON_TV0_GATE, CLK_BUS_TCON_TOP_TV0},
+ {"bus-tcon-top-tv1", TCON_TOP_TCON_TV1_GATE, CLK_BUS_TCON_TOP_TV1},
+};
+
+static int sun8i_tcon_top_get_connected_ep_id(struct device_node *node,
+ int port_id)
+{
+ struct device_node *ep, *remote, *port;
+ struct of_endpoint endpoint;
+
+ port = of_graph_get_port_by_id(node, port_id);
+ if (!port)
+ return -ENOENT;
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ continue;
+
+ if (of_device_is_available(remote)) {
+ of_graph_parse_endpoint(ep, &endpoint);
+
+ of_node_put(remote);
+
+ return endpoint.id;
+ }
+
+ of_node_put(remote);
+ }
+
+ return -ENOENT;
+}
+
+static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct clk_hw_onecell_data *clk_data;
+ struct sun8i_tcon_top *tcon_top;
+ bool mixer0_unused = false;
+ struct resource *res;
+ void __iomem *regs;
+ const char *parent;
+ int ret, i, id;
+ u32 val;
+
+ tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
+ if (!tcon_top)
+ return -ENOMEM;
+
+ clk_data = devm_kzalloc(dev, sizeof(*clk_data) +
+ sizeof(*clk_data->hws) * CLK_NUM,
+ GFP_KERNEL);
+ if (!clk_data)
+ return -ENOMEM;
+ tcon_top->clk_data = clk_data;
+
+ spin_lock_init(&tcon_top->reg_lock);
+
+ tcon_top->rst = devm_reset_control_get(dev, "rst");
+ if (IS_ERR(tcon_top->rst)) {
+ dev_err(dev, "Couldn't get our reset line\n");
+ return PTR_ERR(tcon_top->rst);
+ }
+
+ tcon_top->bus = devm_clk_get(dev, "bus");
+ if (IS_ERR(tcon_top->bus)) {
+ dev_err(dev, "Couldn't get the bus clock\n");
+ return PTR_ERR(tcon_top->bus);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ ret = reset_control_deassert(tcon_top->rst);
+ if (ret) {
+ dev_err(dev, "Could not deassert ctrl reset control\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(tcon_top->bus);
+ if (ret) {
+ dev_err(dev, "Could not enable bus clock\n");
+ goto err_assert_reset;
+ }
+
+ val = 0;
+
+ /* check if HDMI mux output is connected */
+ if (sun8i_tcon_top_get_connected_ep_id(dev->of_node, 5) >= 0) {
+ /* find HDMI input endpoint id, if it is connected at all*/
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 4);
+ if (id >= 0)
+ val = FIELD_PREP(TCON_TOP_HDMI_SRC_MSK, id + 1);
+ else
+ DRM_DEBUG_DRIVER("TCON TOP HDMI input is not connected\n");
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP HDMI output is not connected\n");
+ }
+
+ writel(val, regs + TCON_TOP_GATE_SRC_REG);
+
+ val = 0;
+
+ /* process mixer0 mux output */
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 1);
+ if (id >= 0) {
+ val = FIELD_PREP(TCON_TOP_PORT_DE0_MSK, id);
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP mixer0 output is not connected\n");
+ mixer0_unused = true;
+ }
+
+ /* process mixer1 mux output */
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 3);
+ if (id >= 0) {
+ val |= FIELD_PREP(TCON_TOP_PORT_DE1_MSK, id);
+
+ /*
+ * mixer0 mux has priority over mixer1 mux. We have to
+ * make sure mixer0 doesn't overtake TCON from mixer1.
+ */
+ if (mixer0_unused && id == 0)
+ val |= FIELD_PREP(TCON_TOP_PORT_DE0_MSK, 1);
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP mixer1 output is not connected\n");
+ }
+
+ writel(val, regs + TCON_TOP_PORT_SEL_REG);
+
+ parent = __clk_get_name(tcon_top->bus);
+
+ for (i = 0; i < CLK_NUM; i++) {
+ const struct sun8i_tcon_top_gate *gate = &gates[i];
+ struct clk_hw *hw;
+
+ hw = clk_hw_register_gate(dev, gate->name, parent, 0,
+ regs + TCON_TOP_GATE_SRC_REG,
+ gate->bit, 0, &tcon_top->reg_lock);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
+ goto err_unregister_gates;
+ }
+
+ clk_data->hws[gate->index] = hw;
+ }
+
+ clk_data->num = CLK_NUM;
+
+ ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
+ clk_data);
+ if (ret)
+ goto err_unregister_gates;
+
+ dev_set_drvdata(dev, tcon_top);
+
+ return 0;
+
+err_unregister_gates:
+ for (i = 0; i < CLK_NUM; i++)
+ if (clk_data->hws[i])
+ clk_hw_unregister_gate(clk_data->hws[i]);
+ clk_disable_unprepare(tcon_top->bus);
+err_assert_reset:
+ reset_control_assert(tcon_top->rst);
+
+ return ret;
+}
+
+static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
+ struct clk_hw_onecell_data *clk_data = tcon_top->clk_data;
+ int i;
+
+ of_clk_del_provider(dev->of_node);
+ for (i = 0; i < CLK_NUM; i++)
+ clk_hw_unregister_gate(clk_data->hws[i]);
+
+ clk_disable_unprepare(tcon_top->bus);
+ reset_control_assert(tcon_top->rst);
+}
+
+static const struct component_ops sun8i_tcon_top_ops = {
+ .bind = sun8i_tcon_top_bind,
+ .unbind = sun8i_tcon_top_unbind,
+};
+
+static int sun8i_tcon_top_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &sun8i_tcon_top_ops);
+}
+
+static int sun8i_tcon_top_remove(struct platform_device *pdev)
+{
+ component_del(&pdev->dev, &sun8i_tcon_top_ops);
+
+ return 0;
+}
+
+/* sun4i_drv uses this list to check if a device node is a TCON TOP */
+const struct of_device_id sun8i_tcon_top_of_table[] = {
+ { .compatible = "allwinner,sun8i-r40-tcon-top" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun8i_tcon_top_of_table);
+EXPORT_SYMBOL(sun8i_tcon_top_of_table);
+
+static struct platform_driver sun8i_tcon_top_platform_driver = {
+ .probe = sun8i_tcon_top_probe,
+ .remove = sun8i_tcon_top_remove,
+ .driver = {
+ .name = "sun8i-tcon-top",
+ .of_match_table = sun8i_tcon_top_of_table,
+ },
+};
+module_platform_driver(sun8i_tcon_top_platform_driver);
+
+MODULE_AUTHOR("Jernej Skrabec <jernej.skrabec@siol.net>");
+MODULE_DESCRIPTION("Allwinner R40 TCON TOP driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.h b/drivers/gpu/drm/sun4i/sun8i_tcon_top.h
new file mode 100644
index 000000000000..6cbb9f90d702
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/* Copyright (c) 2018 Jernej Skrabec <jernej.skrabec@siol.net> */
+
+#ifndef _SUN8I_TCON_TOP_H_
+#define _SUN8I_TCON_TOP_H_
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/reset.h>
+#include <linux/spinlock.h>
+
+#define TCON_TOP_PORT_SEL_REG 0x1C
+#define TCON_TOP_PORT_DE0_MSK GENMASK(1, 0)
+#define TCON_TOP_PORT_DE1_MSK GENMASK(5, 4)
+
+#define TCON_TOP_GATE_SRC_REG 0x20
+#define TCON_TOP_HDMI_SRC_MSK GENMASK(29, 28)
+#define TCON_TOP_TCON_TV1_GATE 24
+#define TCON_TOP_TCON_TV0_GATE 20
+#define TCON_TOP_TCON_DSI_GATE 16
+
+#define CLK_NUM 3
+
+struct sun8i_tcon_top {
+ struct clk *bus;
+ struct clk_hw_onecell_data *clk_data;
+ struct reset_control *rst;
+
+ /*
+ * spinlock is used for locking access to registers from different
+ * places - tcon driver and clk subsystem.
+ */
+ spinlock_t reg_lock;
+};
+
+extern const struct of_device_id sun8i_tcon_top_of_table[];
+
+#endif /* _SUN8I_TCON_TOP_H_ */
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 05/27] drm/sun4i: Add TCON TOP driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
As already described in DT binding, TCON TOP is responsible for
configuring display pipeline. In this initial driver focus is on HDMI
pipeline, so TVE and LCD configuration is not implemented.
Implemented features:
- HDMI source selection
- clock driver (TCON and DSI gating)
- connecting mixers and TCONS
Something similar also existed in previous SoCs, except that it was part
of first TCON.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 248 +++++++++++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 38 ++++
3 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2589f4acd5ae..09fbfd6304ba 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -16,7 +16,8 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
- sun8i_vi_scaler.o sun8i_csc.o
+ sun8i_vi_scaler.o sun8i_csc.o \
+ sun8i_tcon_top.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
new file mode 100644
index 000000000000..60b17e893f08
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2018 Jernej Skrabec <jernej.skrabec@siol.net> */
+
+#include <drm/drmP.h>
+
+#include <dt-bindings/clock/sun8i-tcon-top.h>
+
+#include <linux/bitfield.h>
+#include <linux/component.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+
+#include "sun8i_tcon_top.h"
+
+struct sun8i_tcon_top_gate {
+ const char *name;
+ u8 bit;
+ int index;
+};
+
+static const struct sun8i_tcon_top_gate gates[] = {
+ {"bus-tcon-top-dsi", TCON_TOP_TCON_DSI_GATE, CLK_BUS_TCON_TOP_DSI},
+ {"bus-tcon-top-tv0", TCON_TOP_TCON_TV0_GATE, CLK_BUS_TCON_TOP_TV0},
+ {"bus-tcon-top-tv1", TCON_TOP_TCON_TV1_GATE, CLK_BUS_TCON_TOP_TV1},
+};
+
+static int sun8i_tcon_top_get_connected_ep_id(struct device_node *node,
+ int port_id)
+{
+ struct device_node *ep, *remote, *port;
+ struct of_endpoint endpoint;
+
+ port = of_graph_get_port_by_id(node, port_id);
+ if (!port)
+ return -ENOENT;
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ continue;
+
+ if (of_device_is_available(remote)) {
+ of_graph_parse_endpoint(ep, &endpoint);
+
+ of_node_put(remote);
+
+ return endpoint.id;
+ }
+
+ of_node_put(remote);
+ }
+
+ return -ENOENT;
+}
+
+static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct clk_hw_onecell_data *clk_data;
+ struct sun8i_tcon_top *tcon_top;
+ bool mixer0_unused = false;
+ struct resource *res;
+ void __iomem *regs;
+ const char *parent;
+ int ret, i, id;
+ u32 val;
+
+ tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
+ if (!tcon_top)
+ return -ENOMEM;
+
+ clk_data = devm_kzalloc(dev, sizeof(*clk_data) +
+ sizeof(*clk_data->hws) * CLK_NUM,
+ GFP_KERNEL);
+ if (!clk_data)
+ return -ENOMEM;
+ tcon_top->clk_data = clk_data;
+
+ spin_lock_init(&tcon_top->reg_lock);
+
+ tcon_top->rst = devm_reset_control_get(dev, "rst");
+ if (IS_ERR(tcon_top->rst)) {
+ dev_err(dev, "Couldn't get our reset line\n");
+ return PTR_ERR(tcon_top->rst);
+ }
+
+ tcon_top->bus = devm_clk_get(dev, "bus");
+ if (IS_ERR(tcon_top->bus)) {
+ dev_err(dev, "Couldn't get the bus clock\n");
+ return PTR_ERR(tcon_top->bus);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ ret = reset_control_deassert(tcon_top->rst);
+ if (ret) {
+ dev_err(dev, "Could not deassert ctrl reset control\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(tcon_top->bus);
+ if (ret) {
+ dev_err(dev, "Could not enable bus clock\n");
+ goto err_assert_reset;
+ }
+
+ val = 0;
+
+ /* check if HDMI mux output is connected */
+ if (sun8i_tcon_top_get_connected_ep_id(dev->of_node, 5) >= 0) {
+ /* find HDMI input endpoint id, if it is connected at all*/
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 4);
+ if (id >= 0)
+ val = FIELD_PREP(TCON_TOP_HDMI_SRC_MSK, id + 1);
+ else
+ DRM_DEBUG_DRIVER("TCON TOP HDMI input is not connected\n");
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP HDMI output is not connected\n");
+ }
+
+ writel(val, regs + TCON_TOP_GATE_SRC_REG);
+
+ val = 0;
+
+ /* process mixer0 mux output */
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 1);
+ if (id >= 0) {
+ val = FIELD_PREP(TCON_TOP_PORT_DE0_MSK, id);
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP mixer0 output is not connected\n");
+ mixer0_unused = true;
+ }
+
+ /* process mixer1 mux output */
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 3);
+ if (id >= 0) {
+ val |= FIELD_PREP(TCON_TOP_PORT_DE1_MSK, id);
+
+ /*
+ * mixer0 mux has priority over mixer1 mux. We have to
+ * make sure mixer0 doesn't overtake TCON from mixer1.
+ */
+ if (mixer0_unused && id == 0)
+ val |= FIELD_PREP(TCON_TOP_PORT_DE0_MSK, 1);
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP mixer1 output is not connected\n");
+ }
+
+ writel(val, regs + TCON_TOP_PORT_SEL_REG);
+
+ parent = __clk_get_name(tcon_top->bus);
+
+ for (i = 0; i < CLK_NUM; i++) {
+ const struct sun8i_tcon_top_gate *gate = &gates[i];
+ struct clk_hw *hw;
+
+ hw = clk_hw_register_gate(dev, gate->name, parent, 0,
+ regs + TCON_TOP_GATE_SRC_REG,
+ gate->bit, 0, &tcon_top->reg_lock);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
+ goto err_unregister_gates;
+ }
+
+ clk_data->hws[gate->index] = hw;
+ }
+
+ clk_data->num = CLK_NUM;
+
+ ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
+ clk_data);
+ if (ret)
+ goto err_unregister_gates;
+
+ dev_set_drvdata(dev, tcon_top);
+
+ return 0;
+
+err_unregister_gates:
+ for (i = 0; i < CLK_NUM; i++)
+ if (clk_data->hws[i])
+ clk_hw_unregister_gate(clk_data->hws[i]);
+ clk_disable_unprepare(tcon_top->bus);
+err_assert_reset:
+ reset_control_assert(tcon_top->rst);
+
+ return ret;
+}
+
+static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
+ struct clk_hw_onecell_data *clk_data = tcon_top->clk_data;
+ int i;
+
+ of_clk_del_provider(dev->of_node);
+ for (i = 0; i < CLK_NUM; i++)
+ clk_hw_unregister_gate(clk_data->hws[i]);
+
+ clk_disable_unprepare(tcon_top->bus);
+ reset_control_assert(tcon_top->rst);
+}
+
+static const struct component_ops sun8i_tcon_top_ops = {
+ .bind = sun8i_tcon_top_bind,
+ .unbind = sun8i_tcon_top_unbind,
+};
+
+static int sun8i_tcon_top_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &sun8i_tcon_top_ops);
+}
+
+static int sun8i_tcon_top_remove(struct platform_device *pdev)
+{
+ component_del(&pdev->dev, &sun8i_tcon_top_ops);
+
+ return 0;
+}
+
+/* sun4i_drv uses this list to check if a device node is a TCON TOP */
+const struct of_device_id sun8i_tcon_top_of_table[] = {
+ { .compatible = "allwinner,sun8i-r40-tcon-top" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun8i_tcon_top_of_table);
+EXPORT_SYMBOL(sun8i_tcon_top_of_table);
+
+static struct platform_driver sun8i_tcon_top_platform_driver = {
+ .probe = sun8i_tcon_top_probe,
+ .remove = sun8i_tcon_top_remove,
+ .driver = {
+ .name = "sun8i-tcon-top",
+ .of_match_table = sun8i_tcon_top_of_table,
+ },
+};
+module_platform_driver(sun8i_tcon_top_platform_driver);
+
+MODULE_AUTHOR("Jernej Skrabec <jernej.skrabec@siol.net>");
+MODULE_DESCRIPTION("Allwinner R40 TCON TOP driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.h b/drivers/gpu/drm/sun4i/sun8i_tcon_top.h
new file mode 100644
index 000000000000..6cbb9f90d702
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/* Copyright (c) 2018 Jernej Skrabec <jernej.skrabec@siol.net> */
+
+#ifndef _SUN8I_TCON_TOP_H_
+#define _SUN8I_TCON_TOP_H_
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/reset.h>
+#include <linux/spinlock.h>
+
+#define TCON_TOP_PORT_SEL_REG 0x1C
+#define TCON_TOP_PORT_DE0_MSK GENMASK(1, 0)
+#define TCON_TOP_PORT_DE1_MSK GENMASK(5, 4)
+
+#define TCON_TOP_GATE_SRC_REG 0x20
+#define TCON_TOP_HDMI_SRC_MSK GENMASK(29, 28)
+#define TCON_TOP_TCON_TV1_GATE 24
+#define TCON_TOP_TCON_TV0_GATE 20
+#define TCON_TOP_TCON_DSI_GATE 16
+
+#define CLK_NUM 3
+
+struct sun8i_tcon_top {
+ struct clk *bus;
+ struct clk_hw_onecell_data *clk_data;
+ struct reset_control *rst;
+
+ /*
+ * spinlock is used for locking access to registers from different
+ * places - tcon driver and clk subsystem.
+ */
+ spinlock_t reg_lock;
+};
+
+extern const struct of_device_id sun8i_tcon_top_of_table[];
+
+#endif /* _SUN8I_TCON_TOP_H_ */
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 05/27] drm/sun4i: Add TCON TOP driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
As already described in DT binding, TCON TOP is responsible for
configuring display pipeline. In this initial driver focus is on HDMI
pipeline, so TVE and LCD configuration is not implemented.
Implemented features:
- HDMI source selection
- clock driver (TCON and DSI gating)
- connecting mixers and TCONS
Something similar also existed in previous SoCs, except that it was part
of first TCON.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/Makefile | 3 +-
drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 248 +++++++++++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 38 ++++
3 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2589f4acd5ae..09fbfd6304ba 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -16,7 +16,8 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
- sun8i_vi_scaler.o sun8i_csc.o
+ sun8i_vi_scaler.o sun8i_csc.o \
+ sun8i_tcon_top.o
sun4i-tcon-y += sun4i_crtc.o
sun4i-tcon-y += sun4i_dotclock.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
new file mode 100644
index 000000000000..60b17e893f08
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (c) 2018 Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> */
+
+#include <drm/drmP.h>
+
+#include <dt-bindings/clock/sun8i-tcon-top.h>
+
+#include <linux/bitfield.h>
+#include <linux/component.h>
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/of_graph.h>
+#include <linux/platform_device.h>
+
+#include "sun8i_tcon_top.h"
+
+struct sun8i_tcon_top_gate {
+ const char *name;
+ u8 bit;
+ int index;
+};
+
+static const struct sun8i_tcon_top_gate gates[] = {
+ {"bus-tcon-top-dsi", TCON_TOP_TCON_DSI_GATE, CLK_BUS_TCON_TOP_DSI},
+ {"bus-tcon-top-tv0", TCON_TOP_TCON_TV0_GATE, CLK_BUS_TCON_TOP_TV0},
+ {"bus-tcon-top-tv1", TCON_TOP_TCON_TV1_GATE, CLK_BUS_TCON_TOP_TV1},
+};
+
+static int sun8i_tcon_top_get_connected_ep_id(struct device_node *node,
+ int port_id)
+{
+ struct device_node *ep, *remote, *port;
+ struct of_endpoint endpoint;
+
+ port = of_graph_get_port_by_id(node, port_id);
+ if (!port)
+ return -ENOENT;
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ continue;
+
+ if (of_device_is_available(remote)) {
+ of_graph_parse_endpoint(ep, &endpoint);
+
+ of_node_put(remote);
+
+ return endpoint.id;
+ }
+
+ of_node_put(remote);
+ }
+
+ return -ENOENT;
+}
+
+static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct clk_hw_onecell_data *clk_data;
+ struct sun8i_tcon_top *tcon_top;
+ bool mixer0_unused = false;
+ struct resource *res;
+ void __iomem *regs;
+ const char *parent;
+ int ret, i, id;
+ u32 val;
+
+ tcon_top = devm_kzalloc(dev, sizeof(*tcon_top), GFP_KERNEL);
+ if (!tcon_top)
+ return -ENOMEM;
+
+ clk_data = devm_kzalloc(dev, sizeof(*clk_data) +
+ sizeof(*clk_data->hws) * CLK_NUM,
+ GFP_KERNEL);
+ if (!clk_data)
+ return -ENOMEM;
+ tcon_top->clk_data = clk_data;
+
+ spin_lock_init(&tcon_top->reg_lock);
+
+ tcon_top->rst = devm_reset_control_get(dev, "rst");
+ if (IS_ERR(tcon_top->rst)) {
+ dev_err(dev, "Couldn't get our reset line\n");
+ return PTR_ERR(tcon_top->rst);
+ }
+
+ tcon_top->bus = devm_clk_get(dev, "bus");
+ if (IS_ERR(tcon_top->bus)) {
+ dev_err(dev, "Couldn't get the bus clock\n");
+ return PTR_ERR(tcon_top->bus);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+
+ ret = reset_control_deassert(tcon_top->rst);
+ if (ret) {
+ dev_err(dev, "Could not deassert ctrl reset control\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(tcon_top->bus);
+ if (ret) {
+ dev_err(dev, "Could not enable bus clock\n");
+ goto err_assert_reset;
+ }
+
+ val = 0;
+
+ /* check if HDMI mux output is connected */
+ if (sun8i_tcon_top_get_connected_ep_id(dev->of_node, 5) >= 0) {
+ /* find HDMI input endpoint id, if it is connected at all*/
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 4);
+ if (id >= 0)
+ val = FIELD_PREP(TCON_TOP_HDMI_SRC_MSK, id + 1);
+ else
+ DRM_DEBUG_DRIVER("TCON TOP HDMI input is not connected\n");
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP HDMI output is not connected\n");
+ }
+
+ writel(val, regs + TCON_TOP_GATE_SRC_REG);
+
+ val = 0;
+
+ /* process mixer0 mux output */
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 1);
+ if (id >= 0) {
+ val = FIELD_PREP(TCON_TOP_PORT_DE0_MSK, id);
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP mixer0 output is not connected\n");
+ mixer0_unused = true;
+ }
+
+ /* process mixer1 mux output */
+ id = sun8i_tcon_top_get_connected_ep_id(dev->of_node, 3);
+ if (id >= 0) {
+ val |= FIELD_PREP(TCON_TOP_PORT_DE1_MSK, id);
+
+ /*
+ * mixer0 mux has priority over mixer1 mux. We have to
+ * make sure mixer0 doesn't overtake TCON from mixer1.
+ */
+ if (mixer0_unused && id == 0)
+ val |= FIELD_PREP(TCON_TOP_PORT_DE0_MSK, 1);
+ } else {
+ DRM_DEBUG_DRIVER("TCON TOP mixer1 output is not connected\n");
+ }
+
+ writel(val, regs + TCON_TOP_PORT_SEL_REG);
+
+ parent = __clk_get_name(tcon_top->bus);
+
+ for (i = 0; i < CLK_NUM; i++) {
+ const struct sun8i_tcon_top_gate *gate = &gates[i];
+ struct clk_hw *hw;
+
+ hw = clk_hw_register_gate(dev, gate->name, parent, 0,
+ regs + TCON_TOP_GATE_SRC_REG,
+ gate->bit, 0, &tcon_top->reg_lock);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
+ goto err_unregister_gates;
+ }
+
+ clk_data->hws[gate->index] = hw;
+ }
+
+ clk_data->num = CLK_NUM;
+
+ ret = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
+ clk_data);
+ if (ret)
+ goto err_unregister_gates;
+
+ dev_set_drvdata(dev, tcon_top);
+
+ return 0;
+
+err_unregister_gates:
+ for (i = 0; i < CLK_NUM; i++)
+ if (clk_data->hws[i])
+ clk_hw_unregister_gate(clk_data->hws[i]);
+ clk_disable_unprepare(tcon_top->bus);
+err_assert_reset:
+ reset_control_assert(tcon_top->rst);
+
+ return ret;
+}
+
+static void sun8i_tcon_top_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct sun8i_tcon_top *tcon_top = dev_get_drvdata(dev);
+ struct clk_hw_onecell_data *clk_data = tcon_top->clk_data;
+ int i;
+
+ of_clk_del_provider(dev->of_node);
+ for (i = 0; i < CLK_NUM; i++)
+ clk_hw_unregister_gate(clk_data->hws[i]);
+
+ clk_disable_unprepare(tcon_top->bus);
+ reset_control_assert(tcon_top->rst);
+}
+
+static const struct component_ops sun8i_tcon_top_ops = {
+ .bind = sun8i_tcon_top_bind,
+ .unbind = sun8i_tcon_top_unbind,
+};
+
+static int sun8i_tcon_top_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &sun8i_tcon_top_ops);
+}
+
+static int sun8i_tcon_top_remove(struct platform_device *pdev)
+{
+ component_del(&pdev->dev, &sun8i_tcon_top_ops);
+
+ return 0;
+}
+
+/* sun4i_drv uses this list to check if a device node is a TCON TOP */
+const struct of_device_id sun8i_tcon_top_of_table[] = {
+ { .compatible = "allwinner,sun8i-r40-tcon-top" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sun8i_tcon_top_of_table);
+EXPORT_SYMBOL(sun8i_tcon_top_of_table);
+
+static struct platform_driver sun8i_tcon_top_platform_driver = {
+ .probe = sun8i_tcon_top_probe,
+ .remove = sun8i_tcon_top_remove,
+ .driver = {
+ .name = "sun8i-tcon-top",
+ .of_match_table = sun8i_tcon_top_of_table,
+ },
+};
+module_platform_driver(sun8i_tcon_top_platform_driver);
+
+MODULE_AUTHOR("Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>");
+MODULE_DESCRIPTION("Allwinner R40 TCON TOP driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.h b/drivers/gpu/drm/sun4i/sun8i_tcon_top.h
new file mode 100644
index 000000000000..6cbb9f90d702
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.h
@@ -0,0 +1,38 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/* Copyright (c) 2018 Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> */
+
+#ifndef _SUN8I_TCON_TOP_H_
+#define _SUN8I_TCON_TOP_H_
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/reset.h>
+#include <linux/spinlock.h>
+
+#define TCON_TOP_PORT_SEL_REG 0x1C
+#define TCON_TOP_PORT_DE0_MSK GENMASK(1, 0)
+#define TCON_TOP_PORT_DE1_MSK GENMASK(5, 4)
+
+#define TCON_TOP_GATE_SRC_REG 0x20
+#define TCON_TOP_HDMI_SRC_MSK GENMASK(29, 28)
+#define TCON_TOP_TCON_TV1_GATE 24
+#define TCON_TOP_TCON_TV0_GATE 20
+#define TCON_TOP_TCON_DSI_GATE 16
+
+#define CLK_NUM 3
+
+struct sun8i_tcon_top {
+ struct clk *bus;
+ struct clk_hw_onecell_data *clk_data;
+ struct reset_control *rst;
+
+ /*
+ * spinlock is used for locking access to registers from different
+ * places - tcon driver and clk subsystem.
+ */
+ spinlock_t reg_lock;
+};
+
+extern const struct of_device_id sun8i_tcon_top_of_table[];
+
+#endif /* _SUN8I_TCON_TOP_H_ */
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 05/27] drm/sun4i: Add TCON TOP driver
2018-06-12 20:00 ` Jernej Skrabec
(?)
@ 2018-06-13 7:07 ` kbuild test robot
-1 siblings, 0 replies; 201+ messages in thread
From: kbuild test robot @ 2018-06-13 7:07 UTC (permalink / raw)
To: Jernej Skrabec
Cc: kbuild-all, maxime.ripard, wens, robh+dt, airlied, gustavo,
maarten.lankhorst, seanpaul, mark.rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
Hi Jernej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17 next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jernej-Skrabec/clk-sunxi-ng-r40-Add-minimal-rate-for-video-PLLs/20180613-041046
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `init_module':
>> sun8i_tcon_top.c:(.init.text+0x0): multiple definition of `init_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.init.text+0x0): first defined here
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `cleanup_module':
>> sun8i_tcon_top.c:(.exit.text+0x0): multiple definition of `cleanup_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.exit.text+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 43418 bytes --]
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 05/27] drm/sun4i: Add TCON TOP driver
@ 2018-06-13 7:07 ` kbuild test robot
0 siblings, 0 replies; 201+ messages in thread
From: kbuild test robot @ 2018-06-13 7:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jernej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17 next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jernej-Skrabec/clk-sunxi-ng-r40-Add-minimal-rate-for-video-PLLs/20180613-041046
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `init_module':
>> sun8i_tcon_top.c:(.init.text+0x0): multiple definition of `init_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.init.text+0x0): first defined here
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `cleanup_module':
>> sun8i_tcon_top.c:(.exit.text+0x0): multiple definition of `cleanup_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.exit.text+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43418 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/44b6eb84/attachment-0001.gz>
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 05/27] drm/sun4i: Add TCON TOP driver
@ 2018-06-13 7:07 ` kbuild test robot
0 siblings, 0 replies; 201+ messages in thread
From: kbuild test robot @ 2018-06-13 7:07 UTC (permalink / raw)
To: Jernej Skrabec
Cc: mark.rutland, devicetree, maxime.ripard, linux-sunxi,
linux-kernel, dri-devel, airlied, wens, robh+dt, kbuild-all,
linux-clk, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
Hi Jernej,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17 next-20180612]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jernej-Skrabec/clk-sunxi-ng-r40-Add-minimal-rate-for-video-PLLs/20180613-041046
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-multi_v7_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `init_module':
>> sun8i_tcon_top.c:(.init.text+0x0): multiple definition of `init_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.init.text+0x0): first defined here
drivers/gpu/drm/sun4i/sun8i_tcon_top.o: In function `cleanup_module':
>> sun8i_tcon_top.c:(.exit.text+0x0): multiple definition of `cleanup_module'
drivers/gpu/drm/sun4i/sun8i_mixer.o:sun8i_mixer.c:(.exit.text+0x0): first defined here
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 43418 bytes --]
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 06/27] drm/sun4i: Fix releasing node when enumerating enpoints
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put()
when remote is equal to NULL and does nothing when remote has a valid
pointer.
Invert the logic to fix memory leak.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 50d19605c38f..e15fa2389e3f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -283,7 +283,6 @@ static int sun4i_drv_add_endpoints(struct device *dev,
remote = of_graph_get_remote_port_parent(ep);
if (!remote) {
DRM_DEBUG_DRIVER("Error retrieving the output node\n");
- of_node_put(remote);
continue;
}
@@ -297,11 +296,13 @@ static int sun4i_drv_add_endpoints(struct device *dev,
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
continue;
}
if (!endpoint.id) {
DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
continue;
}
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 06/27] drm/sun4i: Fix releasing node when enumerating enpoints
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put()
when remote is equal to NULL and does nothing when remote has a valid
pointer.
Invert the logic to fix memory leak.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 50d19605c38f..e15fa2389e3f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -283,7 +283,6 @@ static int sun4i_drv_add_endpoints(struct device *dev,
remote = of_graph_get_remote_port_parent(ep);
if (!remote) {
DRM_DEBUG_DRIVER("Error retrieving the output node\n");
- of_node_put(remote);
continue;
}
@@ -297,11 +296,13 @@ static int sun4i_drv_add_endpoints(struct device *dev,
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
continue;
}
if (!endpoint.id) {
DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
continue;
}
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 06/27] drm/sun4i: Fix releasing node when enumerating enpoints
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: mark.rutland, devicetree, airlied, gustavo, maarten.lankhorst,
linux-kernel, dri-devel, linux-sunxi, seanpaul, linux-clk,
linux-arm-kernel
sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put()
when remote is equal to NULL and does nothing when remote has a valid
pointer.
Invert the logic to fix memory leak.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 50d19605c38f..e15fa2389e3f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -283,7 +283,6 @@ static int sun4i_drv_add_endpoints(struct device *dev,
remote = of_graph_get_remote_port_parent(ep);
if (!remote) {
DRM_DEBUG_DRIVER("Error retrieving the output node\n");
- of_node_put(remote);
continue;
}
@@ -297,11 +296,13 @@ static int sun4i_drv_add_endpoints(struct device *dev,
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
continue;
}
if (!endpoint.id) {
DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
continue;
}
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 06/27] drm/sun4i: Fix releasing node when enumerating enpoints
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put()
when remote is equal to NULL and does nothing when remote has a valid
pointer.
Invert the logic to fix memory leak.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 50d19605c38f..e15fa2389e3f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -283,7 +283,6 @@ static int sun4i_drv_add_endpoints(struct device *dev,
remote = of_graph_get_remote_port_parent(ep);
if (!remote) {
DRM_DEBUG_DRIVER("Error retrieving the output node\n");
- of_node_put(remote);
continue;
}
@@ -297,11 +296,13 @@ static int sun4i_drv_add_endpoints(struct device *dev,
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
continue;
}
if (!endpoint.id) {
DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
continue;
}
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 07/27] drm/sun4i: Split out code for enumerating endpoints in output port
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Until now, each node has one input port and one output port. However,
with TCON TOP this is no longer true. It has 3 input and 3 output ports.
In order to prepare to this situation, split out the code which checks
all endpoints in input port and adds available components to fifo.
This patch doesn't do any functional change.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 84 +++++++++++++++++--------------
1 file changed, 46 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e15fa2389e3f..20193d6f33ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -231,12 +231,55 @@ struct endpoint_list {
DECLARE_KFIFO(fifo, struct device_node *, 16);
};
+static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
+ struct device_node *node,
+ int port_id)
+{
+ struct device_node *ep, *remote, *port;
+
+ port = of_graph_get_port_by_id(node, port_id);
+ if (!port) {
+ DRM_DEBUG_DRIVER("No output to bind on port %d\n", port_id);
+ return;
+ }
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote) {
+ DRM_DEBUG_DRIVER("Error retrieving the output node\n");
+ continue;
+ }
+
+ /*
+ * If the node is our TCON, the first port is used for
+ * panel or bridges, and will not be part of the
+ * component framework.
+ */
+ if (sun4i_drv_node_is_tcon(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
+ }
+
+ kfifo_put(&list->fifo, remote);
+ }
+}
+
static int sun4i_drv_add_endpoints(struct device *dev,
struct endpoint_list *list,
struct component_match **match,
struct device_node *node)
{
- struct device_node *port, *ep, *remote;
int count = 0;
/*
@@ -272,43 +315,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
count++;
}
- /* Inputs are listed first, then outputs */
- port = of_graph_get_port_by_id(node, 1);
- if (!port) {
- DRM_DEBUG_DRIVER("No output to bind\n");
- return count;
- }
-
- for_each_available_child_of_node(port, ep) {
- remote = of_graph_get_remote_port_parent(ep);
- if (!remote) {
- DRM_DEBUG_DRIVER("Error retrieving the output node\n");
- continue;
- }
-
- /*
- * If the node is our TCON, the first port is used for
- * panel or bridges, and will not be part of the
- * component framework.
- */
- if (sun4i_drv_node_is_tcon(node)) {
- struct of_endpoint endpoint;
-
- if (of_graph_parse_endpoint(ep, &endpoint)) {
- DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
- of_node_put(remote);
- continue;
- }
-
- if (!endpoint.id) {
- DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
- of_node_put(remote);
- continue;
- }
- }
-
- kfifo_put(&list->fifo, remote);
- }
+ /* each node has at least one output */
+ sun4i_drv_traverse_endpoints(list, node, 1);
return count;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 07/27] drm/sun4i: Split out code for enumerating endpoints in output port
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Until now, each node has one input port and one output port. However,
with TCON TOP this is no longer true. It has 3 input and 3 output ports.
In order to prepare to this situation, split out the code which checks
all endpoints in input port and adds available components to fifo.
This patch doesn't do any functional change.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 84 +++++++++++++++++--------------
1 file changed, 46 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e15fa2389e3f..20193d6f33ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -231,12 +231,55 @@ struct endpoint_list {
DECLARE_KFIFO(fifo, struct device_node *, 16);
};
+static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
+ struct device_node *node,
+ int port_id)
+{
+ struct device_node *ep, *remote, *port;
+
+ port = of_graph_get_port_by_id(node, port_id);
+ if (!port) {
+ DRM_DEBUG_DRIVER("No output to bind on port %d\n", port_id);
+ return;
+ }
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote) {
+ DRM_DEBUG_DRIVER("Error retrieving the output node\n");
+ continue;
+ }
+
+ /*
+ * If the node is our TCON, the first port is used for
+ * panel or bridges, and will not be part of the
+ * component framework.
+ */
+ if (sun4i_drv_node_is_tcon(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
+ }
+
+ kfifo_put(&list->fifo, remote);
+ }
+}
+
static int sun4i_drv_add_endpoints(struct device *dev,
struct endpoint_list *list,
struct component_match **match,
struct device_node *node)
{
- struct device_node *port, *ep, *remote;
int count = 0;
/*
@@ -272,43 +315,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
count++;
}
- /* Inputs are listed first, then outputs */
- port = of_graph_get_port_by_id(node, 1);
- if (!port) {
- DRM_DEBUG_DRIVER("No output to bind\n");
- return count;
- }
-
- for_each_available_child_of_node(port, ep) {
- remote = of_graph_get_remote_port_parent(ep);
- if (!remote) {
- DRM_DEBUG_DRIVER("Error retrieving the output node\n");
- continue;
- }
-
- /*
- * If the node is our TCON, the first port is used for
- * panel or bridges, and will not be part of the
- * component framework.
- */
- if (sun4i_drv_node_is_tcon(node)) {
- struct of_endpoint endpoint;
-
- if (of_graph_parse_endpoint(ep, &endpoint)) {
- DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
- of_node_put(remote);
- continue;
- }
-
- if (!endpoint.id) {
- DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
- of_node_put(remote);
- continue;
- }
- }
-
- kfifo_put(&list->fifo, remote);
- }
+ /* each node has at least one output */
+ sun4i_drv_traverse_endpoints(list, node, 1);
return count;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 07/27] drm/sun4i: Split out code for enumerating endpoints in output port
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Until now, each node has one input port and one output port. However,
with TCON TOP this is no longer true. It has 3 input and 3 output ports.
In order to prepare to this situation, split out the code which checks
all endpoints in input port and adds available components to fifo.
This patch doesn't do any functional change.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 84 +++++++++++++++++--------------
1 file changed, 46 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e15fa2389e3f..20193d6f33ba 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -231,12 +231,55 @@ struct endpoint_list {
DECLARE_KFIFO(fifo, struct device_node *, 16);
};
+static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
+ struct device_node *node,
+ int port_id)
+{
+ struct device_node *ep, *remote, *port;
+
+ port = of_graph_get_port_by_id(node, port_id);
+ if (!port) {
+ DRM_DEBUG_DRIVER("No output to bind on port %d\n", port_id);
+ return;
+ }
+
+ for_each_available_child_of_node(port, ep) {
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote) {
+ DRM_DEBUG_DRIVER("Error retrieving the output node\n");
+ continue;
+ }
+
+ /*
+ * If the node is our TCON, the first port is used for
+ * panel or bridges, and will not be part of the
+ * component framework.
+ */
+ if (sun4i_drv_node_is_tcon(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
+ }
+
+ kfifo_put(&list->fifo, remote);
+ }
+}
+
static int sun4i_drv_add_endpoints(struct device *dev,
struct endpoint_list *list,
struct component_match **match,
struct device_node *node)
{
- struct device_node *port, *ep, *remote;
int count = 0;
/*
@@ -272,43 +315,8 @@ static int sun4i_drv_add_endpoints(struct device *dev,
count++;
}
- /* Inputs are listed first, then outputs */
- port = of_graph_get_port_by_id(node, 1);
- if (!port) {
- DRM_DEBUG_DRIVER("No output to bind\n");
- return count;
- }
-
- for_each_available_child_of_node(port, ep) {
- remote = of_graph_get_remote_port_parent(ep);
- if (!remote) {
- DRM_DEBUG_DRIVER("Error retrieving the output node\n");
- continue;
- }
-
- /*
- * If the node is our TCON, the first port is used for
- * panel or bridges, and will not be part of the
- * component framework.
- */
- if (sun4i_drv_node_is_tcon(node)) {
- struct of_endpoint endpoint;
-
- if (of_graph_parse_endpoint(ep, &endpoint)) {
- DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
- of_node_put(remote);
- continue;
- }
-
- if (!endpoint.id) {
- DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
- of_node_put(remote);
- continue;
- }
- }
-
- kfifo_put(&list->fifo, remote);
- }
+ /* each node has at least one output */
+ sun4i_drv_traverse_endpoints(list, node, 1);
return count;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 08/27] drm/sun4i: Add support for traversing graph with TCON TOP
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
TCON TOP is different from other nodes in graph by having 3 input and 3
output ports. Additionally, connection to TV TCON might lead back to
HDMI mux input port, creating loops.
Add support for traversing such graph.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 20193d6f33ba..e6c62c079146 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -26,6 +26,7 @@
#include "sun4i_frontend.h"
#include "sun4i_framebuffer.h"
#include "sun4i_tcon.h"
+#include "sun8i_tcon_top.h"
DEFINE_DRM_GEM_CMA_FOPS(sun4i_drv_fops);
@@ -197,6 +198,11 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
static int compare_of(struct device *dev, void *data)
{
DRM_DEBUG_DRIVER("Comparing of node %pOF with %pOF\n",
@@ -258,6 +264,18 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
if (sun4i_drv_node_is_tcon(node)) {
struct of_endpoint endpoint;
+ /*
+ * TCON TOP is always probed before TCON. However, TCON
+ * points back to TCON TOP when it is source for HDMI.
+ * We have to skip it here to prevent infinite looping
+ * between TCON TOP and TCON.
+ */
+ if (sun4i_drv_node_is_tcon_top(remote)) {
+ DRM_DEBUG_DRIVER("TCON output endpoint is TCON TOP... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
+
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
of_node_put(remote);
@@ -318,6 +336,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
/* each node has at least one output */
sun4i_drv_traverse_endpoints(list, node, 1);
+ /* TCON TOP has second and third output */
+ if (sun4i_drv_node_is_tcon_top(node)) {
+ sun4i_drv_traverse_endpoints(list, node, 3);
+ sun4i_drv_traverse_endpoints(list, node, 5);
+ }
+
return count;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 08/27] drm/sun4i: Add support for traversing graph with TCON TOP
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
TCON TOP is different from other nodes in graph by having 3 input and 3
output ports. Additionally, connection to TV TCON might lead back to
HDMI mux input port, creating loops.
Add support for traversing such graph.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 20193d6f33ba..e6c62c079146 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -26,6 +26,7 @@
#include "sun4i_frontend.h"
#include "sun4i_framebuffer.h"
#include "sun4i_tcon.h"
+#include "sun8i_tcon_top.h"
DEFINE_DRM_GEM_CMA_FOPS(sun4i_drv_fops);
@@ -197,6 +198,11 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
static int compare_of(struct device *dev, void *data)
{
DRM_DEBUG_DRIVER("Comparing of node %pOF with %pOF\n",
@@ -258,6 +264,18 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
if (sun4i_drv_node_is_tcon(node)) {
struct of_endpoint endpoint;
+ /*
+ * TCON TOP is always probed before TCON. However, TCON
+ * points back to TCON TOP when it is source for HDMI.
+ * We have to skip it here to prevent infinite looping
+ * between TCON TOP and TCON.
+ */
+ if (sun4i_drv_node_is_tcon_top(remote)) {
+ DRM_DEBUG_DRIVER("TCON output endpoint is TCON TOP... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
+
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
of_node_put(remote);
@@ -318,6 +336,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
/* each node has at least one output */
sun4i_drv_traverse_endpoints(list, node, 1);
+ /* TCON TOP has second and third output */
+ if (sun4i_drv_node_is_tcon_top(node)) {
+ sun4i_drv_traverse_endpoints(list, node, 3);
+ sun4i_drv_traverse_endpoints(list, node, 5);
+ }
+
return count;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 08/27] drm/sun4i: Add support for traversing graph with TCON TOP
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: mark.rutland, devicetree, airlied, gustavo, maarten.lankhorst,
linux-kernel, dri-devel, linux-sunxi, seanpaul, linux-clk,
linux-arm-kernel
TCON TOP is different from other nodes in graph by having 3 input and 3
output ports. Additionally, connection to TV TCON might lead back to
HDMI mux input port, creating loops.
Add support for traversing such graph.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 20193d6f33ba..e6c62c079146 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -26,6 +26,7 @@
#include "sun4i_frontend.h"
#include "sun4i_framebuffer.h"
#include "sun4i_tcon.h"
+#include "sun8i_tcon_top.h"
DEFINE_DRM_GEM_CMA_FOPS(sun4i_drv_fops);
@@ -197,6 +198,11 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
static int compare_of(struct device *dev, void *data)
{
DRM_DEBUG_DRIVER("Comparing of node %pOF with %pOF\n",
@@ -258,6 +264,18 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
if (sun4i_drv_node_is_tcon(node)) {
struct of_endpoint endpoint;
+ /*
+ * TCON TOP is always probed before TCON. However, TCON
+ * points back to TCON TOP when it is source for HDMI.
+ * We have to skip it here to prevent infinite looping
+ * between TCON TOP and TCON.
+ */
+ if (sun4i_drv_node_is_tcon_top(remote)) {
+ DRM_DEBUG_DRIVER("TCON output endpoint is TCON TOP... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
+
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
of_node_put(remote);
@@ -318,6 +336,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
/* each node has at least one output */
sun4i_drv_traverse_endpoints(list, node, 1);
+ /* TCON TOP has second and third output */
+ if (sun4i_drv_node_is_tcon_top(node)) {
+ sun4i_drv_traverse_endpoints(list, node, 3);
+ sun4i_drv_traverse_endpoints(list, node, 5);
+ }
+
return count;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 08/27] drm/sun4i: Add support for traversing graph with TCON TOP
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
TCON TOP is different from other nodes in graph by having 3 input and 3
output ports. Additionally, connection to TV TCON might lead back to
HDMI mux input port, creating loops.
Add support for traversing such graph.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 20193d6f33ba..e6c62c079146 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -26,6 +26,7 @@
#include "sun4i_frontend.h"
#include "sun4i_framebuffer.h"
#include "sun4i_tcon.h"
+#include "sun8i_tcon_top.h"
DEFINE_DRM_GEM_CMA_FOPS(sun4i_drv_fops);
@@ -197,6 +198,11 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
static int compare_of(struct device *dev, void *data)
{
DRM_DEBUG_DRIVER("Comparing of node %pOF with %pOF\n",
@@ -258,6 +264,18 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
if (sun4i_drv_node_is_tcon(node)) {
struct of_endpoint endpoint;
+ /*
+ * TCON TOP is always probed before TCON. However, TCON
+ * points back to TCON TOP when it is source for HDMI.
+ * We have to skip it here to prevent infinite looping
+ * between TCON TOP and TCON.
+ */
+ if (sun4i_drv_node_is_tcon_top(remote)) {
+ DRM_DEBUG_DRIVER("TCON output endpoint is TCON TOP... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
+
if (of_graph_parse_endpoint(ep, &endpoint)) {
DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
of_node_put(remote);
@@ -318,6 +336,12 @@ static int sun4i_drv_add_endpoints(struct device *dev,
/* each node has at least one output */
sun4i_drv_traverse_endpoints(list, node, 1);
+ /* TCON TOP has second and third output */
+ if (sun4i_drv_node_is_tcon_top(node)) {
+ sun4i_drv_traverse_endpoints(list, node, 3);
+ sun4i_drv_traverse_endpoints(list, node, 5);
+ }
+
return count;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 09/27] drm/sun4i: Don't skip TCONs if they don't have channel 0
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
TV TCONs (channel 1 only) are always connected to TV or HDMI encoder.
Because of that, all output endpoints on such TCON node will point to a
encoder which is part of component framework.
Correct current graph traversing algorithm in such way that it doesn't
skip output enpoints with id 0 on TV TCONs.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 52 +++++++++++++++++++++----------
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e6c62c079146..6ddf4eaccb40 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -198,6 +198,22 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_with_ch0(struct device_node *node)
+{
+ const struct of_device_id *match;
+
+ match = of_match_node(sun4i_tcon_of_table, node);
+ if (match) {
+ struct sun4i_tcon_quirks *quirks;
+
+ quirks = (struct sun4i_tcon_quirks *)match->data;
+
+ return quirks->has_channel_0;
+ }
+
+ return false;
+}
+
static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
{
return !!of_match_node(sun8i_tcon_top_of_table, node);
@@ -256,14 +272,7 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- /*
- * If the node is our TCON, the first port is used for
- * panel or bridges, and will not be part of the
- * component framework.
- */
if (sun4i_drv_node_is_tcon(node)) {
- struct of_endpoint endpoint;
-
/*
* TCON TOP is always probed before TCON. However, TCON
* points back to TCON TOP when it is source for HDMI.
@@ -276,16 +285,25 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- if (of_graph_parse_endpoint(ep, &endpoint)) {
- DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
- of_node_put(remote);
- continue;
- }
-
- if (!endpoint.id) {
- DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
- of_node_put(remote);
- continue;
+ /*
+ * If the node is our TCON with channel 0, the first
+ * port is used for panel or bridges, and will not be
+ * part of the component framework.
+ */
+ if (sun4i_drv_node_is_tcon_with_ch0(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
}
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 09/27] drm/sun4i: Don't skip TCONs if they don't have channel 0
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
TV TCONs (channel 1 only) are always connected to TV or HDMI encoder.
Because of that, all output endpoints on such TCON node will point to a
encoder which is part of component framework.
Correct current graph traversing algorithm in such way that it doesn't
skip output enpoints with id 0 on TV TCONs.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 52 +++++++++++++++++++++----------
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e6c62c079146..6ddf4eaccb40 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -198,6 +198,22 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_with_ch0(struct device_node *node)
+{
+ const struct of_device_id *match;
+
+ match = of_match_node(sun4i_tcon_of_table, node);
+ if (match) {
+ struct sun4i_tcon_quirks *quirks;
+
+ quirks = (struct sun4i_tcon_quirks *)match->data;
+
+ return quirks->has_channel_0;
+ }
+
+ return false;
+}
+
static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
{
return !!of_match_node(sun8i_tcon_top_of_table, node);
@@ -256,14 +272,7 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- /*
- * If the node is our TCON, the first port is used for
- * panel or bridges, and will not be part of the
- * component framework.
- */
if (sun4i_drv_node_is_tcon(node)) {
- struct of_endpoint endpoint;
-
/*
* TCON TOP is always probed before TCON. However, TCON
* points back to TCON TOP when it is source for HDMI.
@@ -276,16 +285,25 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- if (of_graph_parse_endpoint(ep, &endpoint)) {
- DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
- of_node_put(remote);
- continue;
- }
-
- if (!endpoint.id) {
- DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
- of_node_put(remote);
- continue;
+ /*
+ * If the node is our TCON with channel 0, the first
+ * port is used for panel or bridges, and will not be
+ * part of the component framework.
+ */
+ if (sun4i_drv_node_is_tcon_with_ch0(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
}
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 09/27] drm/sun4i: Don't skip TCONs if they don't have channel 0
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: mark.rutland, devicetree, airlied, gustavo, maarten.lankhorst,
linux-kernel, dri-devel, linux-sunxi, seanpaul, linux-clk,
linux-arm-kernel
TV TCONs (channel 1 only) are always connected to TV or HDMI encoder.
Because of that, all output endpoints on such TCON node will point to a
encoder which is part of component framework.
Correct current graph traversing algorithm in such way that it doesn't
skip output enpoints with id 0 on TV TCONs.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 52 +++++++++++++++++++++----------
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e6c62c079146..6ddf4eaccb40 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -198,6 +198,22 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_with_ch0(struct device_node *node)
+{
+ const struct of_device_id *match;
+
+ match = of_match_node(sun4i_tcon_of_table, node);
+ if (match) {
+ struct sun4i_tcon_quirks *quirks;
+
+ quirks = (struct sun4i_tcon_quirks *)match->data;
+
+ return quirks->has_channel_0;
+ }
+
+ return false;
+}
+
static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
{
return !!of_match_node(sun8i_tcon_top_of_table, node);
@@ -256,14 +272,7 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- /*
- * If the node is our TCON, the first port is used for
- * panel or bridges, and will not be part of the
- * component framework.
- */
if (sun4i_drv_node_is_tcon(node)) {
- struct of_endpoint endpoint;
-
/*
* TCON TOP is always probed before TCON. However, TCON
* points back to TCON TOP when it is source for HDMI.
@@ -276,16 +285,25 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- if (of_graph_parse_endpoint(ep, &endpoint)) {
- DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
- of_node_put(remote);
- continue;
- }
-
- if (!endpoint.id) {
- DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
- of_node_put(remote);
- continue;
+ /*
+ * If the node is our TCON with channel 0, the first
+ * port is used for panel or bridges, and will not be
+ * part of the component framework.
+ */
+ if (sun4i_drv_node_is_tcon_with_ch0(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
}
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 09/27] drm/sun4i: Don't skip TCONs if they don't have channel 0
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
TV TCONs (channel 1 only) are always connected to TV or HDMI encoder.
Because of that, all output endpoints on such TCON node will point to a
encoder which is part of component framework.
Correct current graph traversing algorithm in such way that it doesn't
skip output enpoints with id 0 on TV TCONs.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 52 +++++++++++++++++++++----------
1 file changed, 35 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c b/drivers/gpu/drm/sun4i/sun4i_drv.c
index e6c62c079146..6ddf4eaccb40 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -198,6 +198,22 @@ static bool sun4i_drv_node_is_tcon(struct device_node *node)
return !!of_match_node(sun4i_tcon_of_table, node);
}
+static bool sun4i_drv_node_is_tcon_with_ch0(struct device_node *node)
+{
+ const struct of_device_id *match;
+
+ match = of_match_node(sun4i_tcon_of_table, node);
+ if (match) {
+ struct sun4i_tcon_quirks *quirks;
+
+ quirks = (struct sun4i_tcon_quirks *)match->data;
+
+ return quirks->has_channel_0;
+ }
+
+ return false;
+}
+
static bool sun4i_drv_node_is_tcon_top(struct device_node *node)
{
return !!of_match_node(sun8i_tcon_top_of_table, node);
@@ -256,14 +272,7 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- /*
- * If the node is our TCON, the first port is used for
- * panel or bridges, and will not be part of the
- * component framework.
- */
if (sun4i_drv_node_is_tcon(node)) {
- struct of_endpoint endpoint;
-
/*
* TCON TOP is always probed before TCON. However, TCON
* points back to TCON TOP when it is source for HDMI.
@@ -276,16 +285,25 @@ static void sun4i_drv_traverse_endpoints(struct endpoint_list *list,
continue;
}
- if (of_graph_parse_endpoint(ep, &endpoint)) {
- DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
- of_node_put(remote);
- continue;
- }
-
- if (!endpoint.id) {
- DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
- of_node_put(remote);
- continue;
+ /*
+ * If the node is our TCON with channel 0, the first
+ * port is used for panel or bridges, and will not be
+ * part of the component framework.
+ */
+ if (sun4i_drv_node_is_tcon_with_ch0(node)) {
+ struct of_endpoint endpoint;
+
+ if (of_graph_parse_endpoint(ep, &endpoint)) {
+ DRM_DEBUG_DRIVER("Couldn't parse endpoint\n");
+ of_node_put(remote);
+ continue;
+ }
+
+ if (!endpoint.id) {
+ DRM_DEBUG_DRIVER("Endpoint is our panel... skipping\n");
+ of_node_put(remote);
+ continue;
+ }
}
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
TCON description is expanded with R40 TV TCON compatibles. TV TCONs,
which are connected to TCON TOP muxes, such as those on R40 SoC, also
needs additional clock gate to be specified.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index ef64c589a4b3..68c4b2995624 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -145,6 +145,7 @@ Required properties:
* allwinner,sun8i-a33-tcon
* allwinner,sun8i-a83t-tcon-lcd
* allwinner,sun8i-a83t-tcon-tv
+ * allwinner,sun8i-r40-tcon-tv
* allwinner,sun8i-v3s-tcon
* allwinner,sun9i-a80-tcon-lcd
* allwinner,sun9i-a80-tcon-tv
@@ -178,8 +179,10 @@ For TCONs with channel 0, there is one more clock required:
- 'tcon-ch0': The clock driving the TCON channel 0
For TCONs with channel 1, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
+TV TCONs which are connected to TCON TOP (found in R40 SoC) need one more clock:
+ - 'tcon-top': TV TCON gate found in TCON TOP unit
-When TCON support LVDS (all TCONs except TV TCON on A83T and those found
+When TCON support LVDS (all TCONs except TV TCONs on A83T, R40 and those found
in A13, H3, H5 and V3s SoCs), you need one more reset line:
- 'lvds': The reset line driving the LVDS logic
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
TCON description is expanded with R40 TV TCON compatibles. TV TCONs,
which are connected to TCON TOP muxes, such as those on R40 SoC, also
needs additional clock gate to be specified.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index ef64c589a4b3..68c4b2995624 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -145,6 +145,7 @@ Required properties:
* allwinner,sun8i-a33-tcon
* allwinner,sun8i-a83t-tcon-lcd
* allwinner,sun8i-a83t-tcon-tv
+ * allwinner,sun8i-r40-tcon-tv
* allwinner,sun8i-v3s-tcon
* allwinner,sun9i-a80-tcon-lcd
* allwinner,sun9i-a80-tcon-tv
@@ -178,8 +179,10 @@ For TCONs with channel 0, there is one more clock required:
- 'tcon-ch0': The clock driving the TCON channel 0
For TCONs with channel 1, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
+TV TCONs which are connected to TCON TOP (found in R40 SoC) need one more clock:
+ - 'tcon-top': TV TCON gate found in TCON TOP unit
-When TCON support LVDS (all TCONs except TV TCON on A83T and those found
+When TCON support LVDS (all TCONs except TV TCONs on A83T, R40 and those found
in A13, H3, H5 and V3s SoCs), you need one more reset line:
- 'lvds': The reset line driving the LVDS logic
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
TCON description is expanded with R40 TV TCON compatibles. TV TCONs,
which are connected to TCON TOP muxes, such as those on R40 SoC, also
needs additional clock gate to be specified.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
.../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index ef64c589a4b3..68c4b2995624 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -145,6 +145,7 @@ Required properties:
* allwinner,sun8i-a33-tcon
* allwinner,sun8i-a83t-tcon-lcd
* allwinner,sun8i-a83t-tcon-tv
+ * allwinner,sun8i-r40-tcon-tv
* allwinner,sun8i-v3s-tcon
* allwinner,sun9i-a80-tcon-lcd
* allwinner,sun9i-a80-tcon-tv
@@ -178,8 +179,10 @@ For TCONs with channel 0, there is one more clock required:
- 'tcon-ch0': The clock driving the TCON channel 0
For TCONs with channel 1, there is one more clock required:
- 'tcon-ch1': The clock driving the TCON channel 1
+TV TCONs which are connected to TCON TOP (found in R40 SoC) need one more clock:
+ - 'tcon-top': TV TCON gate found in TCON TOP unit
-When TCON support LVDS (all TCONs except TV TCON on A83T and those found
+When TCON support LVDS (all TCONs except TV TCONs on A83T, R40 and those found
in A13, H3, H5 and V3s SoCs), you need one more reset line:
- 'lvds': The reset line driving the LVDS logic
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
@ 2018-06-20 19:15 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:15 UTC (permalink / raw)
To: Jernej Skrabec
Cc: maxime.ripard, wens, airlied, gustavo, maarten.lankhorst,
seanpaul, mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
On Tue, Jun 12, 2018 at 10:00:19PM +0200, Jernej Skrabec wrote:
> TCON description is expanded with R40 TV TCON compatibles. TV TCONs,
> which are connected to TCON TOP muxes, such as those on R40 SoC, also
> needs additional clock gate to be specified.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
@ 2018-06-20 19:15 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:15 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 12, 2018 at 10:00:19PM +0200, Jernej Skrabec wrote:
> TCON description is expanded with R40 TV TCON compatibles. TV TCONs,
> which are connected to TCON TOP muxes, such as those on R40 SoC, also
> needs additional clock gate to be specified.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
@ 2018-06-20 19:15 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:15 UTC (permalink / raw)
To: Jernej Skrabec
Cc: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
On Tue, Jun 12, 2018 at 10:00:19PM +0200, Jernej Skrabec wrote:
> TCON description is expanded with R40 TV TCON compatibles. TV TCONs,
> which are connected to TCON TOP muxes, such as those on R40 SoC, also
> needs additional clock gate to be specified.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
TV TCONs connected to TCON TOP have to enable additional gate in order
to work.
Add support for such TCONs.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 08747fc3ee71..0afb5a94a414 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
dev_err(dev, "Couldn't get the TCON bus clock\n");
return PTR_ERR(tcon->clk);
}
+
+ if (tcon->quirks->has_tcon_top_gate) {
+ tcon->top_clk = devm_clk_get(dev, "tcon-top");
+ if (IS_ERR(tcon->top_clk)) {
+ dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
+ return PTR_ERR(tcon->top_clk);
+ }
+ clk_prepare_enable(tcon->top_clk);
+ }
+
clk_prepare_enable(tcon->clk);
if (tcon->quirks->has_channel_0) {
@@ -712,6 +722,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
{
clk_disable_unprepare(tcon->clk);
+ clk_disable_unprepare(tcon->top_clk);
}
static int sun4i_tcon_init_irq(struct device *dev,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f6a071cd5a6f..652d5c37d7b4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -224,6 +224,7 @@ struct sun4i_tcon_quirks {
bool needs_de_be_mux; /* sun6i needs mux to select backend */
bool needs_edp_reset; /* a80 edp reset needed for tcon0 access */
bool supports_lvds; /* Does the TCON support an LVDS output? */
+ bool has_tcon_top_gate; /* TCON TOP holds additional gate to enable */
/* callback to handle tcon muxing options */
int (*set_mux)(struct sun4i_tcon *, const struct drm_encoder *);
@@ -249,6 +250,9 @@ struct sun4i_tcon {
u8 dclk_max_div;
u8 dclk_min_div;
+ /* TCON TOP clock */
+ struct clk *top_clk;
+
/* Reset control */
struct reset_control *lcd_rst;
struct reset_control *lvds_rst;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
TV TCONs connected to TCON TOP have to enable additional gate in order
to work.
Add support for such TCONs.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 08747fc3ee71..0afb5a94a414 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
dev_err(dev, "Couldn't get the TCON bus clock\n");
return PTR_ERR(tcon->clk);
}
+
+ if (tcon->quirks->has_tcon_top_gate) {
+ tcon->top_clk = devm_clk_get(dev, "tcon-top");
+ if (IS_ERR(tcon->top_clk)) {
+ dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
+ return PTR_ERR(tcon->top_clk);
+ }
+ clk_prepare_enable(tcon->top_clk);
+ }
+
clk_prepare_enable(tcon->clk);
if (tcon->quirks->has_channel_0) {
@@ -712,6 +722,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
{
clk_disable_unprepare(tcon->clk);
+ clk_disable_unprepare(tcon->top_clk);
}
static int sun4i_tcon_init_irq(struct device *dev,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f6a071cd5a6f..652d5c37d7b4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -224,6 +224,7 @@ struct sun4i_tcon_quirks {
bool needs_de_be_mux; /* sun6i needs mux to select backend */
bool needs_edp_reset; /* a80 edp reset needed for tcon0 access */
bool supports_lvds; /* Does the TCON support an LVDS output? */
+ bool has_tcon_top_gate; /* TCON TOP holds additional gate to enable */
/* callback to handle tcon muxing options */
int (*set_mux)(struct sun4i_tcon *, const struct drm_encoder *);
@@ -249,6 +250,9 @@ struct sun4i_tcon {
u8 dclk_max_div;
u8 dclk_min_div;
+ /* TCON TOP clock */
+ struct clk *top_clk;
+
/* Reset control */
struct reset_control *lcd_rst;
struct reset_control *lvds_rst;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
TV TCONs connected to TCON TOP have to enable additional gate in order
to work.
Add support for such TCONs.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 08747fc3ee71..0afb5a94a414 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
dev_err(dev, "Couldn't get the TCON bus clock\n");
return PTR_ERR(tcon->clk);
}
+
+ if (tcon->quirks->has_tcon_top_gate) {
+ tcon->top_clk = devm_clk_get(dev, "tcon-top");
+ if (IS_ERR(tcon->top_clk)) {
+ dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
+ return PTR_ERR(tcon->top_clk);
+ }
+ clk_prepare_enable(tcon->top_clk);
+ }
+
clk_prepare_enable(tcon->clk);
if (tcon->quirks->has_channel_0) {
@@ -712,6 +722,7 @@ static int sun4i_tcon_init_clocks(struct device *dev,
static void sun4i_tcon_free_clocks(struct sun4i_tcon *tcon)
{
clk_disable_unprepare(tcon->clk);
+ clk_disable_unprepare(tcon->top_clk);
}
static int sun4i_tcon_init_irq(struct device *dev,
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index f6a071cd5a6f..652d5c37d7b4 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -224,6 +224,7 @@ struct sun4i_tcon_quirks {
bool needs_de_be_mux; /* sun6i needs mux to select backend */
bool needs_edp_reset; /* a80 edp reset needed for tcon0 access */
bool supports_lvds; /* Does the TCON support an LVDS output? */
+ bool has_tcon_top_gate; /* TCON TOP holds additional gate to enable */
/* callback to handle tcon muxing options */
int (*set_mux)(struct sun4i_tcon *, const struct drm_encoder *);
@@ -249,6 +250,9 @@ struct sun4i_tcon {
u8 dclk_max_div;
u8 dclk_min_div;
+ /* TCON TOP clock */
+ struct clk *top_clk;
+
/* Reset control */
struct reset_control *lcd_rst;
struct reset_control *lvds_rst;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 8:31 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-15 8:31 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens, robh+dt, airlied, gustavo, maarten.lankhorst, seanpaul,
mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]
Hi,
On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> TV TCONs connected to TCON TOP have to enable additional gate in order
> to work.
>
> Add support for such TCONs.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 08747fc3ee71..0afb5a94a414 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> dev_err(dev, "Couldn't get the TCON bus clock\n");
> return PTR_ERR(tcon->clk);
> }
> +
> + if (tcon->quirks->has_tcon_top_gate) {
> + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> + if (IS_ERR(tcon->top_clk)) {
> + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> + return PTR_ERR(tcon->top_clk);
> + }
> + clk_prepare_enable(tcon->top_clk);
> + }
> +
Is it required for the TCON itself to operate, or does the TCON
requires the TCON TOP, which in turn requires that clock to be
functional?
I find it quite odd to have a clock that isn't meant for a particular
device to actually be wired to another device. I'm not saying this
isn't the case, but it would be a first.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 8:31 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-15 8:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> TV TCONs connected to TCON TOP have to enable additional gate in order
> to work.
>
> Add support for such TCONs.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 08747fc3ee71..0afb5a94a414 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> dev_err(dev, "Couldn't get the TCON bus clock\n");
> return PTR_ERR(tcon->clk);
> }
> +
> + if (tcon->quirks->has_tcon_top_gate) {
> + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> + if (IS_ERR(tcon->top_clk)) {
> + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> + return PTR_ERR(tcon->top_clk);
> + }
> + clk_prepare_enable(tcon->top_clk);
> + }
> +
Is it required for the TCON itself to operate, or does the TCON
requires the TCON TOP, which in turn requires that clock to be
functional?
I find it quite odd to have a clock that isn't meant for a particular
device to actually be wired to another device. I'm not saying this
isn't the case, but it would be a first.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180615/d5a22b93/attachment.sig>
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 8:31 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-15 8:31 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1528 bytes --]
Hi,
On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> TV TCONs connected to TCON TOP have to enable additional gate in order
> to work.
>
> Add support for such TCONs.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index 08747fc3ee71..0afb5a94a414 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> dev_err(dev, "Couldn't get the TCON bus clock\n");
> return PTR_ERR(tcon->clk);
> }
> +
> + if (tcon->quirks->has_tcon_top_gate) {
> + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> + if (IS_ERR(tcon->top_clk)) {
> + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> + return PTR_ERR(tcon->top_clk);
> + }
> + clk_prepare_enable(tcon->top_clk);
> + }
> +
Is it required for the TCON itself to operate, or does the TCON
requires the TCON TOP, which in turn requires that clock to be
functional?
I find it quite odd to have a clock that isn't meant for a particular
device to actually be wired to another device. I'm not saying this
isn't the case, but it would be a first.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
2018-06-15 8:31 ` Maxime Ripard
(?)
@ 2018-06-15 16:41 ` Jernej Škrabec
-1 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 16:41 UTC (permalink / raw)
To: Maxime Ripard
Cc: wens, robh+dt, airlied, gustavo, maarten.lankhorst, seanpaul,
mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
Hi,
Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> > TV TCONs connected to TCON TOP have to enable additional gate in order
> > to work.
> >
> > Add support for such TCONs.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> >
> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > return PTR_ERR(tcon->clk);
> >
> > }
> >
> > +
> > + if (tcon->quirks->has_tcon_top_gate) {
> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > + if (IS_ERR(tcon->top_clk)) {
> > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> > + return PTR_ERR(tcon->top_clk);
> > + }
> > + clk_prepare_enable(tcon->top_clk);
> > + }
> > +
>
> Is it required for the TCON itself to operate, or does the TCON
> requires the TCON TOP, which in turn requires that clock to be
> functional?
>
> I find it quite odd to have a clock that isn't meant for a particular
> device to actually be wired to another device. I'm not saying this
> isn't the case, but it would be a first.
Documentation doesn't say much about that gate. I did few tests and TCON
registers can be read and written even if TCON TOP TV TCON gate is disabled.
However, there is no image, as expected.
More interestingly, I enabled test pattern directly in TCON to eliminate
influence of the mixer. As soon as I disabled that gate, test pattern on HDMI
screen was gone, which suggest that this gate influences something inside
TCON.
Another test I did was that I moved enable/disable gate code to
sun4i_tcon_channel_set_status() and it worked just as well.
I'll ask AW engineer what that gate actually does, but from what I saw, I
would say that most appropriate location to enable/disable TCON TOP TV TCON
gate is TCON driver. Alternatively, TCON TOP driver could check if any TV TCON
is in use and enable appropriate gate. However, that doesn't sound right to me
for some reason.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 16:41 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 16:41 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> > TV TCONs connected to TCON TOP have to enable additional gate in order
> > to work.
> >
> > Add support for such TCONs.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> >
> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > return PTR_ERR(tcon->clk);
> >
> > }
> >
> > +
> > + if (tcon->quirks->has_tcon_top_gate) {
> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > + if (IS_ERR(tcon->top_clk)) {
> > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> > + return PTR_ERR(tcon->top_clk);
> > + }
> > + clk_prepare_enable(tcon->top_clk);
> > + }
> > +
>
> Is it required for the TCON itself to operate, or does the TCON
> requires the TCON TOP, which in turn requires that clock to be
> functional?
>
> I find it quite odd to have a clock that isn't meant for a particular
> device to actually be wired to another device. I'm not saying this
> isn't the case, but it would be a first.
Documentation doesn't say much about that gate. I did few tests and TCON
registers can be read and written even if TCON TOP TV TCON gate is disabled.
However, there is no image, as expected.
More interestingly, I enabled test pattern directly in TCON to eliminate
influence of the mixer. As soon as I disabled that gate, test pattern on HDMI
screen was gone, which suggest that this gate influences something inside
TCON.
Another test I did was that I moved enable/disable gate code to
sun4i_tcon_channel_set_status() and it worked just as well.
I'll ask AW engineer what that gate actually does, but from what I saw, I
would say that most appropriate location to enable/disable TCON TOP TV TCON
gate is TCON driver. Alternatively, TCON TOP driver could check if any TV TCON
is in use and enable appropriate gate. However, that doesn't sound right to me
for some reason.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 16:41 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 16:41 UTC (permalink / raw)
To: Maxime Ripard
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Hi,
Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> Hi,
>
> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> > TV TCONs connected to TCON TOP have to enable additional gate in order
> > to work.
> >
> > Add support for such TCONs.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> > ---
> >
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
> >
> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > return PTR_ERR(tcon->clk);
> >
> > }
> >
> > +
> > + if (tcon->quirks->has_tcon_top_gate) {
> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > + if (IS_ERR(tcon->top_clk)) {
> > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
> > + return PTR_ERR(tcon->top_clk);
> > + }
> > + clk_prepare_enable(tcon->top_clk);
> > + }
> > +
>
> Is it required for the TCON itself to operate, or does the TCON
> requires the TCON TOP, which in turn requires that clock to be
> functional?
>
> I find it quite odd to have a clock that isn't meant for a particular
> device to actually be wired to another device. I'm not saying this
> isn't the case, but it would be a first.
Documentation doesn't say much about that gate. I did few tests and TCON
registers can be read and written even if TCON TOP TV TCON gate is disabled.
However, there is no image, as expected.
More interestingly, I enabled test pattern directly in TCON to eliminate
influence of the mixer. As soon as I disabled that gate, test pattern on HDMI
screen was gone, which suggest that this gate influences something inside
TCON.
Another test I did was that I moved enable/disable gate code to
sun4i_tcon_channel_set_status() and it worked just as well.
I'll ask AW engineer what that gate actually does, but from what I saw, I
would say that most appropriate location to enable/disable TCON TOP TV TCON
gate is TCON driver. Alternatively, TCON TOP driver could check if any TV TCON
is in use and enable appropriate gate. However, that doesn't sound right to me
for some reason.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
2018-06-15 16:41 ` Jernej Škrabec
(?)
@ 2018-06-15 17:13 ` Chen-Yu Tsai
-1 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-15 17:13 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
<jernej.skrabec@siol.net> wrote:
> Hi,
>
> Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> Hi,
>>
>> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> > TV TCONs connected to TCON TOP have to enable additional gate in order
>> > to work.
>> >
>> > Add support for such TCONs.
>> >
>> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> > ---
>> >
>> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> > 2 files changed, 15 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
>> > 100644
>> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
>> >
>> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > return PTR_ERR(tcon->clk);
>> >
>> > }
>> >
>> > +
>> > + if (tcon->quirks->has_tcon_top_gate) {
>> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > + if (IS_ERR(tcon->top_clk)) {
>> > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
>> > + return PTR_ERR(tcon->top_clk);
>> > + }
>> > + clk_prepare_enable(tcon->top_clk);
>> > + }
>> > +
>>
>> Is it required for the TCON itself to operate, or does the TCON
>> requires the TCON TOP, which in turn requires that clock to be
>> functional?
>>
>> I find it quite odd to have a clock that isn't meant for a particular
>> device to actually be wired to another device. I'm not saying this
>> isn't the case, but it would be a first.
>
> Documentation doesn't say much about that gate. I did few tests and TCON
> registers can be read and written even if TCON TOP TV TCON gate is disabled.
> However, there is no image, as expected.
The R40 manual does include it in the diagram, on page 504. There's also a
mux to select whether the clock comes directly from the CCU or the TV encoder
(a feedback mode?). I assume this is the gate you are referring to here, in
which case it is not a bus clock, but rather the TCON module or channel clock,
strangely routed.
> More interestingly, I enabled test pattern directly in TCON to eliminate
> influence of the mixer. As soon as I disabled that gate, test pattern on HDMI
> screen was gone, which suggest that this gate influences something inside
> TCON.
>
> Another test I did was that I moved enable/disable gate code to
> sun4i_tcon_channel_set_status() and it worked just as well.
>
> I'll ask AW engineer what that gate actually does, but from what I saw, I
> would say that most appropriate location to enable/disable TCON TOP TV TCON
> gate is TCON driver. Alternatively, TCON TOP driver could check if any TV TCON
> is in use and enable appropriate gate. However, that doesn't sound right to me
> for some reason.
If what I said above it true, then yes, the appropriate location to enable it
is the TCON driver, but moreover, the representation of the clock tree should
be fixed such that the TCON takes the clock from the TCON TOP as its channel/
module clock instead. That way you don't need this patch, but you'd add another
for all the clock routing.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 17:13 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-15 17:13 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
<jernej.skrabec@siol.net> wrote:
> Hi,
>
> Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> Hi,
>>
>> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> > TV TCONs connected to TCON TOP have to enable additional gate in order
>> > to work.
>> >
>> > Add support for such TCONs.
>> >
>> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> > ---
>> >
>> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> > 2 files changed, 15 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
>> > 100644
>> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
>> >
>> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > return PTR_ERR(tcon->clk);
>> >
>> > }
>> >
>> > +
>> > + if (tcon->quirks->has_tcon_top_gate) {
>> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > + if (IS_ERR(tcon->top_clk)) {
>> > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
>> > + return PTR_ERR(tcon->top_clk);
>> > + }
>> > + clk_prepare_enable(tcon->top_clk);
>> > + }
>> > +
>>
>> Is it required for the TCON itself to operate, or does the TCON
>> requires the TCON TOP, which in turn requires that clock to be
>> functional?
>>
>> I find it quite odd to have a clock that isn't meant for a particular
>> device to actually be wired to another device. I'm not saying this
>> isn't the case, but it would be a first.
>
> Documentation doesn't say much about that gate. I did few tests and TCON
> registers can be read and written even if TCON TOP TV TCON gate is disabled.
> However, there is no image, as expected.
The R40 manual does include it in the diagram, on page 504. There's also a
mux to select whether the clock comes directly from the CCU or the TV encoder
(a feedback mode?). I assume this is the gate you are referring to here, in
which case it is not a bus clock, but rather the TCON module or channel clock,
strangely routed.
> More interestingly, I enabled test pattern directly in TCON to eliminate
> influence of the mixer. As soon as I disabled that gate, test pattern on HDMI
> screen was gone, which suggest that this gate influences something inside
> TCON.
>
> Another test I did was that I moved enable/disable gate code to
> sun4i_tcon_channel_set_status() and it worked just as well.
>
> I'll ask AW engineer what that gate actually does, but from what I saw, I
> would say that most appropriate location to enable/disable TCON TOP TV TCON
> gate is TCON driver. Alternatively, TCON TOP driver could check if any TV TCON
> is in use and enable appropriate gate. However, that doesn't sound right to me
> for some reason.
If what I said above it true, then yes, the appropriate location to enable it
is the TCON driver, but moreover, the representation of the clock tree should
be fixed such that the TCON takes the clock from the TCON TOP as its channel/
module clock instead. That way you don't need this patch, but you'd add another
for all the clock routing.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 17:13 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-15 17:13 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
<jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> Hi,
>
> Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> Hi,
>>
>> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> > TV TCONs connected to TCON TOP have to enable additional gate in order
>> > to work.
>> >
>> > Add support for such TCONs.
>> >
>> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> > ---
>> >
>> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> > 2 files changed, 15 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
>> > 100644
>> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device *dev,
>> >
>> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > return PTR_ERR(tcon->clk);
>> >
>> > }
>> >
>> > +
>> > + if (tcon->quirks->has_tcon_top_gate) {
>> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > + if (IS_ERR(tcon->top_clk)) {
>> > + dev_err(dev, "Couldn't get the TCON TOP bus clock\n");
>> > + return PTR_ERR(tcon->top_clk);
>> > + }
>> > + clk_prepare_enable(tcon->top_clk);
>> > + }
>> > +
>>
>> Is it required for the TCON itself to operate, or does the TCON
>> requires the TCON TOP, which in turn requires that clock to be
>> functional?
>>
>> I find it quite odd to have a clock that isn't meant for a particular
>> device to actually be wired to another device. I'm not saying this
>> isn't the case, but it would be a first.
>
> Documentation doesn't say much about that gate. I did few tests and TCON
> registers can be read and written even if TCON TOP TV TCON gate is disabled.
> However, there is no image, as expected.
The R40 manual does include it in the diagram, on page 504. There's also a
mux to select whether the clock comes directly from the CCU or the TV encoder
(a feedback mode?). I assume this is the gate you are referring to here, in
which case it is not a bus clock, but rather the TCON module or channel clock,
strangely routed.
> More interestingly, I enabled test pattern directly in TCON to eliminate
> influence of the mixer. As soon as I disabled that gate, test pattern on HDMI
> screen was gone, which suggest that this gate influences something inside
> TCON.
>
> Another test I did was that I moved enable/disable gate code to
> sun4i_tcon_channel_set_status() and it worked just as well.
>
> I'll ask AW engineer what that gate actually does, but from what I saw, I
> would say that most appropriate location to enable/disable TCON TOP TV TCON
> gate is TCON driver. Alternatively, TCON TOP driver could check if any TV TCON
> is in use and enable appropriate gate. However, that doesn't sound right to me
> for some reason.
If what I said above it true, then yes, the appropriate location to enable it
is the TCON driver, but moreover, the representation of the clock tree should
be fixed such that the TCON takes the clock from the TCON TOP as its channel/
module clock instead. That way you don't need this patch, but you'd add another
for all the clock routing.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 17:33 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 17:33 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>
> <jernej.skrabec@siol.net> wrote:
> > Hi,
> >
> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> Hi,
> >>
> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
> >> > to work.
> >> >
> >> > Add support for such TCONs.
> >> >
> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > ---
> >> >
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > 2 files changed, 15 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
> >> > 100644
> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> > *dev,
> >> >
> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> > return PTR_ERR(tcon->clk);
> >> >
> >> > }
> >> >
> >> > +
> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> > clock\n");
> >> > + return PTR_ERR(tcon->top_clk);
> >> > + }
> >> > + clk_prepare_enable(tcon->top_clk);
> >> > + }
> >> > +
> >>
> >> Is it required for the TCON itself to operate, or does the TCON
> >> requires the TCON TOP, which in turn requires that clock to be
> >> functional?
> >>
> >> I find it quite odd to have a clock that isn't meant for a particular
> >> device to actually be wired to another device. I'm not saying this
> >> isn't the case, but it would be a first.
> >
> > Documentation doesn't say much about that gate. I did few tests and TCON
> > registers can be read and written even if TCON TOP TV TCON gate is
> > disabled. However, there is no image, as expected.
>
> The R40 manual does include it in the diagram, on page 504. There's also a
> mux to select whether the clock comes directly from the CCU or the TV
> encoder (a feedback mode?). I assume this is the gate you are referring to
> here, in which case it is not a bus clock, but rather the TCON module or
> channel clock, strangely routed.
>
> > More interestingly, I enabled test pattern directly in TCON to eliminate
> > influence of the mixer. As soon as I disabled that gate, test pattern on
> > HDMI screen was gone, which suggest that this gate influences something
> > inside TCON.
> >
> > Another test I did was that I moved enable/disable gate code to
> > sun4i_tcon_channel_set_status() and it worked just as well.
> >
> > I'll ask AW engineer what that gate actually does, but from what I saw, I
> > would say that most appropriate location to enable/disable TCON TOP TV
> > TCON
> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
> > TCON is in use and enable appropriate gate. However, that doesn't sound
> > right to me for some reason.
>
> If what I said above it true, then yes, the appropriate location to enable
> it is the TCON driver, but moreover, the representation of the clock tree
> should be fixed such that the TCON takes the clock from the TCON TOP as its
> channel/ module clock instead. That way you don't need this patch, but
> you'd add another for all the clock routing.
Can you be more specific? I not sure what you mean here.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 17:33 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 17:33 UTC (permalink / raw)
To: linux-arm-kernel
Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
>
> <jernej.skrabec@siol.net> wrote:
> > Hi,
> >
> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> Hi,
> >>
> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
> >> > to work.
> >> >
> >> > Add support for such TCONs.
> >> >
> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > ---
> >> >
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > 2 files changed, 15 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
> >> > 100644
> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> > *dev,
> >> >
> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> > return PTR_ERR(tcon->clk);
> >> >
> >> > }
> >> >
> >> > +
> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> > clock\n");
> >> > + return PTR_ERR(tcon->top_clk);
> >> > + }
> >> > + clk_prepare_enable(tcon->top_clk);
> >> > + }
> >> > +
> >>
> >> Is it required for the TCON itself to operate, or does the TCON
> >> requires the TCON TOP, which in turn requires that clock to be
> >> functional?
> >>
> >> I find it quite odd to have a clock that isn't meant for a particular
> >> device to actually be wired to another device. I'm not saying this
> >> isn't the case, but it would be a first.
> >
> > Documentation doesn't say much about that gate. I did few tests and TCON
> > registers can be read and written even if TCON TOP TV TCON gate is
> > disabled. However, there is no image, as expected.
>
> The R40 manual does include it in the diagram, on page 504. There's also a
> mux to select whether the clock comes directly from the CCU or the TV
> encoder (a feedback mode?). I assume this is the gate you are referring to
> here, in which case it is not a bus clock, but rather the TCON module or
> channel clock, strangely routed.
>
> > More interestingly, I enabled test pattern directly in TCON to eliminate
> > influence of the mixer. As soon as I disabled that gate, test pattern on
> > HDMI screen was gone, which suggest that this gate influences something
> > inside TCON.
> >
> > Another test I did was that I moved enable/disable gate code to
> > sun4i_tcon_channel_set_status() and it worked just as well.
> >
> > I'll ask AW engineer what that gate actually does, but from what I saw, I
> > would say that most appropriate location to enable/disable TCON TOP TV
> > TCON
> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
> > TCON is in use and enable appropriate gate. However, that doesn't sound
> > right to me for some reason.
>
> If what I said above it true, then yes, the appropriate location to enable
> it is the TCON driver, but moreover, the representation of the clock tree
> should be fixed such that the TCON takes the clock from the TCON TOP as its
> channel/ module clock instead. That way you don't need this patch, but
> you'd add another for all the clock routing.
Can you be more specific? I not sure what you mean here.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-15 17:33 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 17:33 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>
> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> > Hi,
> >
> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> Hi,
> >>
> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
> >> > to work.
> >> >
> >> > Add support for such TCONs.
> >> >
> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> > ---
> >> >
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > 2 files changed, 15 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
> >> > 100644
> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> > *dev,
> >> >
> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> > return PTR_ERR(tcon->clk);
> >> >
> >> > }
> >> >
> >> > +
> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> > clock\n");
> >> > + return PTR_ERR(tcon->top_clk);
> >> > + }
> >> > + clk_prepare_enable(tcon->top_clk);
> >> > + }
> >> > +
> >>
> >> Is it required for the TCON itself to operate, or does the TCON
> >> requires the TCON TOP, which in turn requires that clock to be
> >> functional?
> >>
> >> I find it quite odd to have a clock that isn't meant for a particular
> >> device to actually be wired to another device. I'm not saying this
> >> isn't the case, but it would be a first.
> >
> > Documentation doesn't say much about that gate. I did few tests and TCON
> > registers can be read and written even if TCON TOP TV TCON gate is
> > disabled. However, there is no image, as expected.
>
> The R40 manual does include it in the diagram, on page 504. There's also a
> mux to select whether the clock comes directly from the CCU or the TV
> encoder (a feedback mode?). I assume this is the gate you are referring to
> here, in which case it is not a bus clock, but rather the TCON module or
> channel clock, strangely routed.
>
> > More interestingly, I enabled test pattern directly in TCON to eliminate
> > influence of the mixer. As soon as I disabled that gate, test pattern on
> > HDMI screen was gone, which suggest that this gate influences something
> > inside TCON.
> >
> > Another test I did was that I moved enable/disable gate code to
> > sun4i_tcon_channel_set_status() and it worked just as well.
> >
> > I'll ask AW engineer what that gate actually does, but from what I saw, I
> > would say that most appropriate location to enable/disable TCON TOP TV
> > TCON
> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
> > TCON is in use and enable appropriate gate. However, that doesn't sound
> > right to me for some reason.
>
> If what I said above it true, then yes, the appropriate location to enable
> it is the TCON driver, but moreover, the representation of the clock tree
> should be fixed such that the TCON takes the clock from the TCON TOP as its
> channel/ module clock instead. That way you don't need this patch, but
> you'd add another for all the clock routing.
Can you be more specific? I not sure what you mean here.
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
2018-06-15 17:33 ` Jernej Škrabec
(?)
@ 2018-06-16 5:48 ` Chen-Yu Tsai
-1 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-16 5:48 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>>
>> <jernej.skrabec@siol.net> wrote:
>> > Hi,
>> >
>> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> Hi,
>> >>
>> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
>> >> > to work.
>> >> >
>> >> > Add support for such TCONs.
>> >> >
>> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> >> > ---
>> >> >
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> > 2 files changed, 15 insertions(+)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
>> >> > 100644
>> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> > *dev,
>> >> >
>> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> > return PTR_ERR(tcon->clk);
>> >> >
>> >> > }
>> >> >
>> >> > +
>> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> > clock\n");
>> >> > + return PTR_ERR(tcon->top_clk);
>> >> > + }
>> >> > + clk_prepare_enable(tcon->top_clk);
>> >> > + }
>> >> > +
>> >>
>> >> Is it required for the TCON itself to operate, or does the TCON
>> >> requires the TCON TOP, which in turn requires that clock to be
>> >> functional?
>> >>
>> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> device to actually be wired to another device. I'm not saying this
>> >> isn't the case, but it would be a first.
>> >
>> > Documentation doesn't say much about that gate. I did few tests and TCON
>> > registers can be read and written even if TCON TOP TV TCON gate is
>> > disabled. However, there is no image, as expected.
>>
>> The R40 manual does include it in the diagram, on page 504. There's also a
>> mux to select whether the clock comes directly from the CCU or the TV
>> encoder (a feedback mode?). I assume this is the gate you are referring to
>> here, in which case it is not a bus clock, but rather the TCON module or
>> channel clock, strangely routed.
>>
>> > More interestingly, I enabled test pattern directly in TCON to eliminate
>> > influence of the mixer. As soon as I disabled that gate, test pattern on
>> > HDMI screen was gone, which suggest that this gate influences something
>> > inside TCON.
>> >
>> > Another test I did was that I moved enable/disable gate code to
>> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >
>> > I'll ask AW engineer what that gate actually does, but from what I saw, I
>> > would say that most appropriate location to enable/disable TCON TOP TV
>> > TCON
>> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
>> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> > right to me for some reason.
>>
>> If what I said above it true, then yes, the appropriate location to enable
>> it is the TCON driver, but moreover, the representation of the clock tree
>> should be fixed such that the TCON takes the clock from the TCON TOP as its
>> channel/ module clock instead. That way you don't need this patch, but
>> you'd add another for all the clock routing.
>
> Can you be more specific? I not sure what you mean here.
For clock related properties in the device tree:
&tcon_top {
clocks = <&ccu CLK_BUS_TCON_TOP>,
<&ccu CLK_TCON_TV0>,
<&tve0>,
<&ccu CLK_TCON_TV1>,
<&tve1>;
clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
};
&tcon_tv0 {
clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
clock-names = "ahb", "tcon-ch1";
};
A diagram would look like:
| This part is TCON TOP |
v v
CCU CLK_TCON_TV0 --|----\ |
| mux ---- gate ----|-- TCON_TV0
TVE0 --------------|----/ |
And the same goes for TCON_TV1 and TVE1.
The user manual is a bit lacking on how TVE outputs a clock though.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-16 5:48 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-16 5:48 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec <jernej.skrabec@siol.net> wrote:
> Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
>>
>> <jernej.skrabec@siol.net> wrote:
>> > Hi,
>> >
>> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> Hi,
>> >>
>> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
>> >> > to work.
>> >> >
>> >> > Add support for such TCONs.
>> >> >
>> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> >> > ---
>> >> >
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> > 2 files changed, 15 insertions(+)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
>> >> > 100644
>> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> > *dev,
>> >> >
>> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> > return PTR_ERR(tcon->clk);
>> >> >
>> >> > }
>> >> >
>> >> > +
>> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> > clock\n");
>> >> > + return PTR_ERR(tcon->top_clk);
>> >> > + }
>> >> > + clk_prepare_enable(tcon->top_clk);
>> >> > + }
>> >> > +
>> >>
>> >> Is it required for the TCON itself to operate, or does the TCON
>> >> requires the TCON TOP, which in turn requires that clock to be
>> >> functional?
>> >>
>> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> device to actually be wired to another device. I'm not saying this
>> >> isn't the case, but it would be a first.
>> >
>> > Documentation doesn't say much about that gate. I did few tests and TCON
>> > registers can be read and written even if TCON TOP TV TCON gate is
>> > disabled. However, there is no image, as expected.
>>
>> The R40 manual does include it in the diagram, on page 504. There's also a
>> mux to select whether the clock comes directly from the CCU or the TV
>> encoder (a feedback mode?). I assume this is the gate you are referring to
>> here, in which case it is not a bus clock, but rather the TCON module or
>> channel clock, strangely routed.
>>
>> > More interestingly, I enabled test pattern directly in TCON to eliminate
>> > influence of the mixer. As soon as I disabled that gate, test pattern on
>> > HDMI screen was gone, which suggest that this gate influences something
>> > inside TCON.
>> >
>> > Another test I did was that I moved enable/disable gate code to
>> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >
>> > I'll ask AW engineer what that gate actually does, but from what I saw, I
>> > would say that most appropriate location to enable/disable TCON TOP TV
>> > TCON
>> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
>> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> > right to me for some reason.
>>
>> If what I said above it true, then yes, the appropriate location to enable
>> it is the TCON driver, but moreover, the representation of the clock tree
>> should be fixed such that the TCON takes the clock from the TCON TOP as its
>> channel/ module clock instead. That way you don't need this patch, but
>> you'd add another for all the clock routing.
>
> Can you be more specific? I not sure what you mean here.
For clock related properties in the device tree:
&tcon_top {
clocks = <&ccu CLK_BUS_TCON_TOP>,
<&ccu CLK_TCON_TV0>,
<&tve0>,
<&ccu CLK_TCON_TV1>,
<&tve1>;
clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
};
&tcon_tv0 {
clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
clock-names = "ahb", "tcon-ch1";
};
A diagram would look like:
| This part is TCON TOP |
v v
CCU CLK_TCON_TV0 --|----\ |
| mux ---- gate ----|-- TCON_TV0
TVE0 --------------|----/ |
And the same goes for TCON_TV1 and TVE1.
The user manual is a bit lacking on how TVE outputs a clock though.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-16 5:48 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-16 5:48 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>>
>> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
>> > Hi,
>> >
>> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> Hi,
>> >>
>> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> > TV TCONs connected to TCON TOP have to enable additional gate in order
>> >> > to work.
>> >> >
>> >> > Add support for such TCONs.
>> >> >
>> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> >> > ---
>> >> >
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> > 2 files changed, 15 insertions(+)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..0afb5a94a414
>> >> > 100644
>> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> > *dev,
>> >> >
>> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> > return PTR_ERR(tcon->clk);
>> >> >
>> >> > }
>> >> >
>> >> > +
>> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> > clock\n");
>> >> > + return PTR_ERR(tcon->top_clk);
>> >> > + }
>> >> > + clk_prepare_enable(tcon->top_clk);
>> >> > + }
>> >> > +
>> >>
>> >> Is it required for the TCON itself to operate, or does the TCON
>> >> requires the TCON TOP, which in turn requires that clock to be
>> >> functional?
>> >>
>> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> device to actually be wired to another device. I'm not saying this
>> >> isn't the case, but it would be a first.
>> >
>> > Documentation doesn't say much about that gate. I did few tests and TCON
>> > registers can be read and written even if TCON TOP TV TCON gate is
>> > disabled. However, there is no image, as expected.
>>
>> The R40 manual does include it in the diagram, on page 504. There's also a
>> mux to select whether the clock comes directly from the CCU or the TV
>> encoder (a feedback mode?). I assume this is the gate you are referring to
>> here, in which case it is not a bus clock, but rather the TCON module or
>> channel clock, strangely routed.
>>
>> > More interestingly, I enabled test pattern directly in TCON to eliminate
>> > influence of the mixer. As soon as I disabled that gate, test pattern on
>> > HDMI screen was gone, which suggest that this gate influences something
>> > inside TCON.
>> >
>> > Another test I did was that I moved enable/disable gate code to
>> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >
>> > I'll ask AW engineer what that gate actually does, but from what I saw, I
>> > would say that most appropriate location to enable/disable TCON TOP TV
>> > TCON
>> > gate is TCON driver. Alternatively, TCON TOP driver could check if any TV
>> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> > right to me for some reason.
>>
>> If what I said above it true, then yes, the appropriate location to enable
>> it is the TCON driver, but moreover, the representation of the clock tree
>> should be fixed such that the TCON takes the clock from the TCON TOP as its
>> channel/ module clock instead. That way you don't need this patch, but
>> you'd add another for all the clock routing.
>
> Can you be more specific? I not sure what you mean here.
For clock related properties in the device tree:
&tcon_top {
clocks = <&ccu CLK_BUS_TCON_TOP>,
<&ccu CLK_TCON_TV0>,
<&tve0>,
<&ccu CLK_TCON_TV1>,
<&tve1>;
clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
};
&tcon_tv0 {
clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
clock-names = "ahb", "tcon-ch1";
};
A diagram would look like:
| This part is TCON TOP |
v v
CCU CLK_TCON_TV0 --|----\ |
| mux ---- gate ----|-- TCON_TV0
TVE0 --------------|----/ |
And the same goes for TCON_TV1 and TVE1.
The user manual is a bit lacking on how TVE outputs a clock though.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-20 19:37 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-20 19:37 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net>
wrote:
> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >>
> >> <jernej.skrabec@siol.net> wrote:
> >> > Hi,
> >> >
> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> >> Hi,
> >> >>
> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> > order
> >> >> > to work.
> >> >> >
> >> >> > Add support for such TCONs.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> > ---
> >> >> >
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > 2 files changed, 15 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > 100644
> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> >> > *dev,
> >> >> >
> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> > return PTR_ERR(tcon->clk);
> >> >> >
> >> >> > }
> >> >> >
> >> >> > +
> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> > clock\n");
> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > + }
> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > + }
> >> >> > +
> >> >>
> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> functional?
> >> >>
> >> >> I find it quite odd to have a clock that isn't meant for a particular
> >> >> device to actually be wired to another device. I'm not saying this
> >> >> isn't the case, but it would be a first.
> >> >
> >> > Documentation doesn't say much about that gate. I did few tests and
> >> > TCON
> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> > disabled. However, there is no image, as expected.
> >>
> >> The R40 manual does include it in the diagram, on page 504. There's also
> >> a
> >> mux to select whether the clock comes directly from the CCU or the TV
> >> encoder (a feedback mode?). I assume this is the gate you are referring
> >> to
> >> here, in which case it is not a bus clock, but rather the TCON module or
> >> channel clock, strangely routed.
> >>
> >> > More interestingly, I enabled test pattern directly in TCON to
> >> > eliminate
> >> > influence of the mixer. As soon as I disabled that gate, test pattern
> >> > on
> >> > HDMI screen was gone, which suggest that this gate influences something
> >> > inside TCON.
> >> >
> >> > Another test I did was that I moved enable/disable gate code to
> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >
> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
> >> > I
> >> > would say that most appropriate location to enable/disable TCON TOP TV
> >> > TCON
> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
> >> > TV
> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
> >> > right to me for some reason.
> >>
> >> If what I said above it true, then yes, the appropriate location to
> >> enable
> >> it is the TCON driver, but moreover, the representation of the clock tree
> >> should be fixed such that the TCON takes the clock from the TCON TOP as
> >> its
> >> channel/ module clock instead. That way you don't need this patch, but
> >> you'd add another for all the clock routing.
> >
> > Can you be more specific? I not sure what you mean here.
>
> For clock related properties in the device tree:
>
> &tcon_top {
> clocks = <&ccu CLK_BUS_TCON_TOP>,
> <&ccu CLK_TCON_TV0>,
> <&tve0>,
> <&ccu CLK_TCON_TV1>,
> <&tve1>;
> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> };
>
> &tcon_tv0 {
> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> clock-names = "ahb", "tcon-ch1";
> };
>
> A diagram would look like:
> | This part is TCON TOP |
>
> v v
> CCU CLK_TCON_TV0 --|----\ |
>
> | mux ---- gate ----|-- TCON_TV0
>
> TVE0 --------------|----/ |
>
> And the same goes for TCON_TV1 and TVE1.
>
> The user manual is a bit lacking on how TVE outputs a clock though.
I didn't yet received any response on HW details from AW till now, but I would
like to post new version of patches soon.
While chaining like you described could be implemented easily, I don't think
it really represents HW as it is. Tests showed that these two clocks are
independent, otherwise register writes/reads wouldn't be possible with tcon-
top gate disabled. I chose tcon-top bus clock as a parent becase if it is not
enabled, it simply won't work.
However, if everyone feels chaining is the best way to implement it, I'll do
it.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-20 19:37 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-20 19:37 UTC (permalink / raw)
To: linux-arm-kernel
Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec <jernej.skrabec@siol.net>
wrote:
> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
> >>
> >> <jernej.skrabec@siol.net> wrote:
> >> > Hi,
> >> >
> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> >> Hi,
> >> >>
> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> > order
> >> >> > to work.
> >> >> >
> >> >> > Add support for such TCONs.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> > ---
> >> >> >
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > 2 files changed, 15 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > 100644
> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> >> > *dev,
> >> >> >
> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> > return PTR_ERR(tcon->clk);
> >> >> >
> >> >> > }
> >> >> >
> >> >> > +
> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> > clock\n");
> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > + }
> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > + }
> >> >> > +
> >> >>
> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> functional?
> >> >>
> >> >> I find it quite odd to have a clock that isn't meant for a particular
> >> >> device to actually be wired to another device. I'm not saying this
> >> >> isn't the case, but it would be a first.
> >> >
> >> > Documentation doesn't say much about that gate. I did few tests and
> >> > TCON
> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> > disabled. However, there is no image, as expected.
> >>
> >> The R40 manual does include it in the diagram, on page 504. There's also
> >> a
> >> mux to select whether the clock comes directly from the CCU or the TV
> >> encoder (a feedback mode?). I assume this is the gate you are referring
> >> to
> >> here, in which case it is not a bus clock, but rather the TCON module or
> >> channel clock, strangely routed.
> >>
> >> > More interestingly, I enabled test pattern directly in TCON to
> >> > eliminate
> >> > influence of the mixer. As soon as I disabled that gate, test pattern
> >> > on
> >> > HDMI screen was gone, which suggest that this gate influences something
> >> > inside TCON.
> >> >
> >> > Another test I did was that I moved enable/disable gate code to
> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >
> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
> >> > I
> >> > would say that most appropriate location to enable/disable TCON TOP TV
> >> > TCON
> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
> >> > TV
> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
> >> > right to me for some reason.
> >>
> >> If what I said above it true, then yes, the appropriate location to
> >> enable
> >> it is the TCON driver, but moreover, the representation of the clock tree
> >> should be fixed such that the TCON takes the clock from the TCON TOP as
> >> its
> >> channel/ module clock instead. That way you don't need this patch, but
> >> you'd add another for all the clock routing.
> >
> > Can you be more specific? I not sure what you mean here.
>
> For clock related properties in the device tree:
>
> &tcon_top {
> clocks = <&ccu CLK_BUS_TCON_TOP>,
> <&ccu CLK_TCON_TV0>,
> <&tve0>,
> <&ccu CLK_TCON_TV1>,
> <&tve1>;
> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> };
>
> &tcon_tv0 {
> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> clock-names = "ahb", "tcon-ch1";
> };
>
> A diagram would look like:
> | This part is TCON TOP |
>
> v v
> CCU CLK_TCON_TV0 --|----\ |
>
> | mux ---- gate ----|-- TCON_TV0
>
> TVE0 --------------|----/ |
>
> And the same goes for TCON_TV1 and TVE1.
>
> The user manual is a bit lacking on how TVE outputs a clock though.
I didn't yet received any response on HW details from AW till now, but I would
like to post new version of patches soon.
While chaining like you described could be implemented easily, I don't think
it really represents HW as it is. Tests showed that these two clocks are
independent, otherwise register writes/reads wouldn't be possible with tcon-
top gate disabled. I chose tcon-top bus clock as a parent becase if it is not
enabled, it simply won't work.
However, if everyone feels chaining is the best way to implement it, I'll do
it.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-20 19:37 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-20 19:37 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net>
wrote:
> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >>
> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> >> > Hi,
> >> >
> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
> >> >> Hi,
> >> >>
> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> > order
> >> >> > to work.
> >> >> >
> >> >> > Add support for such TCONs.
> >> >> >
> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> >> > ---
> >> >> >
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > 2 files changed, 15 insertions(+)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > 100644
> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
> >> >> > *dev,
> >> >> >
> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> > return PTR_ERR(tcon->clk);
> >> >> >
> >> >> > }
> >> >> >
> >> >> > +
> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> > clock\n");
> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > + }
> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > + }
> >> >> > +
> >> >>
> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> functional?
> >> >>
> >> >> I find it quite odd to have a clock that isn't meant for a particular
> >> >> device to actually be wired to another device. I'm not saying this
> >> >> isn't the case, but it would be a first.
> >> >
> >> > Documentation doesn't say much about that gate. I did few tests and
> >> > TCON
> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> > disabled. However, there is no image, as expected.
> >>
> >> The R40 manual does include it in the diagram, on page 504. There's also
> >> a
> >> mux to select whether the clock comes directly from the CCU or the TV
> >> encoder (a feedback mode?). I assume this is the gate you are referring
> >> to
> >> here, in which case it is not a bus clock, but rather the TCON module or
> >> channel clock, strangely routed.
> >>
> >> > More interestingly, I enabled test pattern directly in TCON to
> >> > eliminate
> >> > influence of the mixer. As soon as I disabled that gate, test pattern
> >> > on
> >> > HDMI screen was gone, which suggest that this gate influences something
> >> > inside TCON.
> >> >
> >> > Another test I did was that I moved enable/disable gate code to
> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >
> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
> >> > I
> >> > would say that most appropriate location to enable/disable TCON TOP TV
> >> > TCON
> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
> >> > TV
> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
> >> > right to me for some reason.
> >>
> >> If what I said above it true, then yes, the appropriate location to
> >> enable
> >> it is the TCON driver, but moreover, the representation of the clock tree
> >> should be fixed such that the TCON takes the clock from the TCON TOP as
> >> its
> >> channel/ module clock instead. That way you don't need this patch, but
> >> you'd add another for all the clock routing.
> >
> > Can you be more specific? I not sure what you mean here.
>
> For clock related properties in the device tree:
>
> &tcon_top {
> clocks = <&ccu CLK_BUS_TCON_TOP>,
> <&ccu CLK_TCON_TV0>,
> <&tve0>,
> <&ccu CLK_TCON_TV1>,
> <&tve1>;
> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> };
>
> &tcon_tv0 {
> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> clock-names = "ahb", "tcon-ch1";
> };
>
> A diagram would look like:
> | This part is TCON TOP |
>
> v v
> CCU CLK_TCON_TV0 --|----\ |
>
> | mux ---- gate ----|-- TCON_TV0
>
> TVE0 --------------|----/ |
>
> And the same goes for TCON_TV1 and TVE1.
>
> The user manual is a bit lacking on how TVE outputs a clock though.
I didn't yet received any response on HW details from AW till now, but I would
like to post new version of patches soon.
While chaining like you described could be implemented easily, I don't think
it really represents HW as it is. Tests showed that these two clocks are
independent, otherwise register writes/reads wouldn't be possible with tcon-
top gate disabled. I chose tcon-top bus clock as a parent becase if it is not
enabled, it simply won't work.
However, if everyone feels chaining is the best way to implement it, I'll do
it.
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
2018-06-20 19:37 ` Jernej Škrabec
(?)
@ 2018-06-21 1:23 ` Chen-Yu Tsai
-1 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-21 1:23 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net>
> wrote:
>> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> >>
>> >> <jernej.skrabec@siol.net> wrote:
>> >> > Hi,
>> >> >
>> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> >> Hi,
>> >> >>
>> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
>> >> >> > order
>> >> >> > to work.
>> >> >> >
>> >> >> > Add support for such TCONs.
>> >> >> >
>> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> >> >> > ---
>> >> >> >
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> >> > 2 files changed, 15 insertions(+)
>> >> >> >
>> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> >> >> > 08747fc3ee71..0afb5a94a414
>> >> >> > 100644
>> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> >> > *dev,
>> >> >> >
>> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> >> > return PTR_ERR(tcon->clk);
>> >> >> >
>> >> >> > }
>> >> >> >
>> >> >> > +
>> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> >> > clock\n");
>> >> >> > + return PTR_ERR(tcon->top_clk);
>> >> >> > + }
>> >> >> > + clk_prepare_enable(tcon->top_clk);
>> >> >> > + }
>> >> >> > +
>> >> >>
>> >> >> Is it required for the TCON itself to operate, or does the TCON
>> >> >> requires the TCON TOP, which in turn requires that clock to be
>> >> >> functional?
>> >> >>
>> >> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> >> device to actually be wired to another device. I'm not saying this
>> >> >> isn't the case, but it would be a first.
>> >> >
>> >> > Documentation doesn't say much about that gate. I did few tests and
>> >> > TCON
>> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> >> > disabled. However, there is no image, as expected.
>> >>
>> >> The R40 manual does include it in the diagram, on page 504. There's also
>> >> a
>> >> mux to select whether the clock comes directly from the CCU or the TV
>> >> encoder (a feedback mode?). I assume this is the gate you are referring
>> >> to
>> >> here, in which case it is not a bus clock, but rather the TCON module or
>> >> channel clock, strangely routed.
>> >>
>> >> > More interestingly, I enabled test pattern directly in TCON to
>> >> > eliminate
>> >> > influence of the mixer. As soon as I disabled that gate, test pattern
>> >> > on
>> >> > HDMI screen was gone, which suggest that this gate influences something
>> >> > inside TCON.
>> >> >
>> >> > Another test I did was that I moved enable/disable gate code to
>> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >> >
>> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
>> >> > I
>> >> > would say that most appropriate location to enable/disable TCON TOP TV
>> >> > TCON
>> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
>> >> > TV
>> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> >> > right to me for some reason.
>> >>
>> >> If what I said above it true, then yes, the appropriate location to
>> >> enable
>> >> it is the TCON driver, but moreover, the representation of the clock tree
>> >> should be fixed such that the TCON takes the clock from the TCON TOP as
>> >> its
>> >> channel/ module clock instead. That way you don't need this patch, but
>> >> you'd add another for all the clock routing.
>> >
>> > Can you be more specific? I not sure what you mean here.
>>
>> For clock related properties in the device tree:
>>
>> &tcon_top {
>> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> <&ccu CLK_TCON_TV0>,
>> <&tve0>,
>> <&ccu CLK_TCON_TV1>,
>> <&tve1>;
>> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> };
>>
>> &tcon_tv0 {
>> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> clock-names = "ahb", "tcon-ch1";
>> };
>>
>> A diagram would look like:
>> | This part is TCON TOP |
>>
>> v v
>> CCU CLK_TCON_TV0 --|----\ |
>>
>> | mux ---- gate ----|-- TCON_TV0
>>
>> TVE0 --------------|----/ |
>>
>> And the same goes for TCON_TV1 and TVE1.
>>
>> The user manual is a bit lacking on how TVE outputs a clock though.
>
> I didn't yet received any response on HW details from AW till now, but I would
> like to post new version of patches soon.
>
> While chaining like you described could be implemented easily, I don't think
> it really represents HW as it is. Tests showed that these two clocks are
> independent, otherwise register writes/reads wouldn't be possible with tcon-
> top gate disabled. I chose tcon-top bus clock as a parent becase if it is not
> enabled, it simply won't work.
AFAIK with the TCONs, even when the TCON channel clock (not the bus clock) is
disabled, register accesses still work. I'm saying that the TCON TOP gate
is downstream from the TCON channel clock in the CCU. These are not related
to the TCON bus clock in the CCU, which affects register access.
Did Allwinner provide any information regarding the hierarchy of the clocks?
> However, if everyone feels chaining is the best way to implement it, I'll do
> it.
I would like to get it right and match actual hardware. My proposal is
based on my understanding from the diagrams in the user manual.
Regards
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-21 1:23 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-21 1:23 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 21, 2018 at 3:37 AM, Jernej ?krabec <jernej.skrabec@siol.net> wrote:
> Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec <jernej.skrabec@siol.net>
> wrote:
>> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
>> >>
>> >> <jernej.skrabec@siol.net> wrote:
>> >> > Hi,
>> >> >
>> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> >> Hi,
>> >> >>
>> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
>> >> >> > order
>> >> >> > to work.
>> >> >> >
>> >> >> > Add support for such TCONs.
>> >> >> >
>> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> >> >> > ---
>> >> >> >
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> >> > 2 files changed, 15 insertions(+)
>> >> >> >
>> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> >> >> > 08747fc3ee71..0afb5a94a414
>> >> >> > 100644
>> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> >> > *dev,
>> >> >> >
>> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> >> > return PTR_ERR(tcon->clk);
>> >> >> >
>> >> >> > }
>> >> >> >
>> >> >> > +
>> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> >> > clock\n");
>> >> >> > + return PTR_ERR(tcon->top_clk);
>> >> >> > + }
>> >> >> > + clk_prepare_enable(tcon->top_clk);
>> >> >> > + }
>> >> >> > +
>> >> >>
>> >> >> Is it required for the TCON itself to operate, or does the TCON
>> >> >> requires the TCON TOP, which in turn requires that clock to be
>> >> >> functional?
>> >> >>
>> >> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> >> device to actually be wired to another device. I'm not saying this
>> >> >> isn't the case, but it would be a first.
>> >> >
>> >> > Documentation doesn't say much about that gate. I did few tests and
>> >> > TCON
>> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> >> > disabled. However, there is no image, as expected.
>> >>
>> >> The R40 manual does include it in the diagram, on page 504. There's also
>> >> a
>> >> mux to select whether the clock comes directly from the CCU or the TV
>> >> encoder (a feedback mode?). I assume this is the gate you are referring
>> >> to
>> >> here, in which case it is not a bus clock, but rather the TCON module or
>> >> channel clock, strangely routed.
>> >>
>> >> > More interestingly, I enabled test pattern directly in TCON to
>> >> > eliminate
>> >> > influence of the mixer. As soon as I disabled that gate, test pattern
>> >> > on
>> >> > HDMI screen was gone, which suggest that this gate influences something
>> >> > inside TCON.
>> >> >
>> >> > Another test I did was that I moved enable/disable gate code to
>> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >> >
>> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
>> >> > I
>> >> > would say that most appropriate location to enable/disable TCON TOP TV
>> >> > TCON
>> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
>> >> > TV
>> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> >> > right to me for some reason.
>> >>
>> >> If what I said above it true, then yes, the appropriate location to
>> >> enable
>> >> it is the TCON driver, but moreover, the representation of the clock tree
>> >> should be fixed such that the TCON takes the clock from the TCON TOP as
>> >> its
>> >> channel/ module clock instead. That way you don't need this patch, but
>> >> you'd add another for all the clock routing.
>> >
>> > Can you be more specific? I not sure what you mean here.
>>
>> For clock related properties in the device tree:
>>
>> &tcon_top {
>> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> <&ccu CLK_TCON_TV0>,
>> <&tve0>,
>> <&ccu CLK_TCON_TV1>,
>> <&tve1>;
>> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> };
>>
>> &tcon_tv0 {
>> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> clock-names = "ahb", "tcon-ch1";
>> };
>>
>> A diagram would look like:
>> | This part is TCON TOP |
>>
>> v v
>> CCU CLK_TCON_TV0 --|----\ |
>>
>> | mux ---- gate ----|-- TCON_TV0
>>
>> TVE0 --------------|----/ |
>>
>> And the same goes for TCON_TV1 and TVE1.
>>
>> The user manual is a bit lacking on how TVE outputs a clock though.
>
> I didn't yet received any response on HW details from AW till now, but I would
> like to post new version of patches soon.
>
> While chaining like you described could be implemented easily, I don't think
> it really represents HW as it is. Tests showed that these two clocks are
> independent, otherwise register writes/reads wouldn't be possible with tcon-
> top gate disabled. I chose tcon-top bus clock as a parent becase if it is not
> enabled, it simply won't work.
AFAIK with the TCONs, even when the TCON channel clock (not the bus clock) is
disabled, register accesses still work. I'm saying that the TCON TOP gate
is downstream from the TCON channel clock in the CCU. These are not related
to the TCON bus clock in the CCU, which affects register access.
Did Allwinner provide any information regarding the hierarchy of the clocks?
> However, if everyone feels chaining is the best way to implement it, I'll do
> it.
I would like to get it right and match actual hardware. My proposal is
based on my understanding from the diagrams in the user manual.
Regards
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-21 1:23 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-21 1:23 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net>
> wrote:
>> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> >>
>> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
>> >> > Hi,
>> >> >
>> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> >> Hi,
>> >> >>
>> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
>> >> >> > order
>> >> >> > to work.
>> >> >> >
>> >> >> > Add support for such TCONs.
>> >> >> >
>> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> >> >> > ---
>> >> >> >
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> >> > 2 files changed, 15 insertions(+)
>> >> >> >
>> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> >> >> > 08747fc3ee71..0afb5a94a414
>> >> >> > 100644
>> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> >> > *dev,
>> >> >> >
>> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> >> > return PTR_ERR(tcon->clk);
>> >> >> >
>> >> >> > }
>> >> >> >
>> >> >> > +
>> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> >> > clock\n");
>> >> >> > + return PTR_ERR(tcon->top_clk);
>> >> >> > + }
>> >> >> > + clk_prepare_enable(tcon->top_clk);
>> >> >> > + }
>> >> >> > +
>> >> >>
>> >> >> Is it required for the TCON itself to operate, or does the TCON
>> >> >> requires the TCON TOP, which in turn requires that clock to be
>> >> >> functional?
>> >> >>
>> >> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> >> device to actually be wired to another device. I'm not saying this
>> >> >> isn't the case, but it would be a first.
>> >> >
>> >> > Documentation doesn't say much about that gate. I did few tests and
>> >> > TCON
>> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> >> > disabled. However, there is no image, as expected.
>> >>
>> >> The R40 manual does include it in the diagram, on page 504. There's also
>> >> a
>> >> mux to select whether the clock comes directly from the CCU or the TV
>> >> encoder (a feedback mode?). I assume this is the gate you are referring
>> >> to
>> >> here, in which case it is not a bus clock, but rather the TCON module or
>> >> channel clock, strangely routed.
>> >>
>> >> > More interestingly, I enabled test pattern directly in TCON to
>> >> > eliminate
>> >> > influence of the mixer. As soon as I disabled that gate, test pattern
>> >> > on
>> >> > HDMI screen was gone, which suggest that this gate influences something
>> >> > inside TCON.
>> >> >
>> >> > Another test I did was that I moved enable/disable gate code to
>> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >> >
>> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
>> >> > I
>> >> > would say that most appropriate location to enable/disable TCON TOP TV
>> >> > TCON
>> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
>> >> > TV
>> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> >> > right to me for some reason.
>> >>
>> >> If what I said above it true, then yes, the appropriate location to
>> >> enable
>> >> it is the TCON driver, but moreover, the representation of the clock tree
>> >> should be fixed such that the TCON takes the clock from the TCON TOP as
>> >> its
>> >> channel/ module clock instead. That way you don't need this patch, but
>> >> you'd add another for all the clock routing.
>> >
>> > Can you be more specific? I not sure what you mean here.
>>
>> For clock related properties in the device tree:
>>
>> &tcon_top {
>> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> <&ccu CLK_TCON_TV0>,
>> <&tve0>,
>> <&ccu CLK_TCON_TV1>,
>> <&tve1>;
>> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> };
>>
>> &tcon_tv0 {
>> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> clock-names = "ahb", "tcon-ch1";
>> };
>>
>> A diagram would look like:
>> | This part is TCON TOP |
>>
>> v v
>> CCU CLK_TCON_TV0 --|----\ |
>>
>> | mux ---- gate ----|-- TCON_TV0
>>
>> TVE0 --------------|----/ |
>>
>> And the same goes for TCON_TV1 and TVE1.
>>
>> The user manual is a bit lacking on how TVE outputs a clock though.
>
> I didn't yet received any response on HW details from AW till now, but I would
> like to post new version of patches soon.
>
> While chaining like you described could be implemented easily, I don't think
> it really represents HW as it is. Tests showed that these two clocks are
> independent, otherwise register writes/reads wouldn't be possible with tcon-
> top gate disabled. I chose tcon-top bus clock as a parent becase if it is not
> enabled, it simply won't work.
AFAIK with the TCONs, even when the TCON channel clock (not the bus clock) is
disabled, register accesses still work. I'm saying that the TCON TOP gate
is downstream from the TCON channel clock in the CCU. These are not related
to the TCON bus clock in the CCU, which affects register access.
Did Allwinner provide any information regarding the hierarchy of the clocks?
> However, if everyone feels chaining is the best way to implement it, I'll do
> it.
I would like to get it right and match actual hardware. My proposal is
based on my understanding from the diagrams in the user manual.
Regards
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-21 15:35 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-21 15:35 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net>
wrote:
> > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >> >>
> >> >> <jernej.skrabec@siol.net> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
napisal(a):
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> >> > order
> >> >> >> > to work.
> >> >> >> >
> >> >> >> > Add support for such TCONs.
> >> >> >> >
> >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> >> > ---
> >> >> >> >
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> >> > 2 files changed, 15 insertions(+)
> >> >> >> >
> >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> >> > 100644
> >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> >> >> >> > device
> >> >> >> > *dev,
> >> >> >> >
> >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> >> > return PTR_ERR(tcon->clk);
> >> >> >> >
> >> >> >> > }
> >> >> >> >
> >> >> >> > +
> >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> >> > clock\n");
> >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > +
> >> >> >>
> >> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> >> functional?
> >> >> >>
> >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> >> >> particular
> >> >> >> device to actually be wired to another device. I'm not saying this
> >> >> >> isn't the case, but it would be a first.
> >> >> >
> >> >> > Documentation doesn't say much about that gate. I did few tests and
> >> >> > TCON
> >> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> >> > disabled. However, there is no image, as expected.
> >> >>
> >> >> The R40 manual does include it in the diagram, on page 504. There's
> >> >> also
> >> >> a
> >> >> mux to select whether the clock comes directly from the CCU or the TV
> >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> >> referring
> >> >> to
> >> >> here, in which case it is not a bus clock, but rather the TCON module
> >> >> or
> >> >> channel clock, strangely routed.
> >> >>
> >> >> > More interestingly, I enabled test pattern directly in TCON to
> >> >> > eliminate
> >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> >> > pattern
> >> >> > on
> >> >> > HDMI screen was gone, which suggest that this gate influences
> >> >> > something
> >> >> > inside TCON.
> >> >> >
> >> >> > Another test I did was that I moved enable/disable gate code to
> >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >> >
> >> >> > I'll ask AW engineer what that gate actually does, but from what I
> >> >> > saw,
> >> >> > I
> >> >> > would say that most appropriate location to enable/disable TCON TOP
> >> >> > TV
> >> >> > TCON
> >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
> >> >> > any
> >> >> > TV
> >> >> > TCON is in use and enable appropriate gate. However, that doesn't
> >> >> > sound
> >> >> > right to me for some reason.
> >> >>
> >> >> If what I said above it true, then yes, the appropriate location to
> >> >> enable
> >> >> it is the TCON driver, but moreover, the representation of the clock
> >> >> tree
> >> >> should be fixed such that the TCON takes the clock from the TCON TOP
> >> >> as
> >> >> its
> >> >> channel/ module clock instead. That way you don't need this patch, but
> >> >> you'd add another for all the clock routing.
> >> >
> >> > Can you be more specific? I not sure what you mean here.
> >>
> >> For clock related properties in the device tree:
> >>
> >> &tcon_top {
> >>
> >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >>
> >> <&ccu CLK_TCON_TV0>,
> >> <&tve0>,
> >> <&ccu CLK_TCON_TV1>,
> >> <&tve1>;
> >>
> >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >>
> >> };
> >>
> >> &tcon_tv0 {
> >>
> >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> clock-names = "ahb", "tcon-ch1";
> >>
> >> };
> >>
> >> A diagram would look like:
> >> | This part is TCON TOP |
> >>
> >> v v
> >>
> >> CCU CLK_TCON_TV0 --|----\ |
> >>
> >> | mux ---- gate ----|-- TCON_TV0
> >>
> >> TVE0 --------------|----/ |
> >>
> >> And the same goes for TCON_TV1 and TVE1.
> >>
> >> The user manual is a bit lacking on how TVE outputs a clock though.
> >
> > I didn't yet received any response on HW details from AW till now, but I
> > would like to post new version of patches soon.
> >
> > While chaining like you described could be implemented easily, I don't
> > think it really represents HW as it is. Tests showed that these two
> > clocks are independent, otherwise register writes/reads wouldn't be
> > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
> > parent becase if it is not enabled, it simply won't work.
>
> AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
> is disabled, register accesses still work.
You're right, I just tested that.
> I'm saying that the TCON TOP
> gate is downstream from the TCON channel clock in the CCU. These are not
> related to the TCON bus clock in the CCU, which affects register access.
>
> Did Allwinner provide any information regarding the hierarchy of the clocks?
No reponse for now.
> > However, if everyone feels chaining is the best way to implement it, I'll
> > do it.
>
> I would like to get it right and match actual hardware. My proposal is
> based on my understanding from the diagrams in the user manual.
So for now, your explanation is the most reasonable. Should we go ahead and
implement your idea?
Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one TV
TCON instead of two of each kind. That means we will have hole in indices
(tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and different TCON-
TOP binding (no tcon_tv1 channel clock), but setup is exactly the same.
Best regard,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-21 15:35 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
Dne ?etrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> On Thu, Jun 21, 2018 at 3:37 AM, Jernej ?krabec <jernej.skrabec@siol.net>
wrote:
> > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
> >> >>
> >> >> <jernej.skrabec@siol.net> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
napisal(a):
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> >> > order
> >> >> >> > to work.
> >> >> >> >
> >> >> >> > Add support for such TCONs.
> >> >> >> >
> >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> >> > ---
> >> >> >> >
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> >> > 2 files changed, 15 insertions(+)
> >> >> >> >
> >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> >> > 100644
> >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> >> >> >> > device
> >> >> >> > *dev,
> >> >> >> >
> >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> >> > return PTR_ERR(tcon->clk);
> >> >> >> >
> >> >> >> > }
> >> >> >> >
> >> >> >> > +
> >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> >> > clock\n");
> >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > +
> >> >> >>
> >> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> >> functional?
> >> >> >>
> >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> >> >> particular
> >> >> >> device to actually be wired to another device. I'm not saying this
> >> >> >> isn't the case, but it would be a first.
> >> >> >
> >> >> > Documentation doesn't say much about that gate. I did few tests and
> >> >> > TCON
> >> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> >> > disabled. However, there is no image, as expected.
> >> >>
> >> >> The R40 manual does include it in the diagram, on page 504. There's
> >> >> also
> >> >> a
> >> >> mux to select whether the clock comes directly from the CCU or the TV
> >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> >> referring
> >> >> to
> >> >> here, in which case it is not a bus clock, but rather the TCON module
> >> >> or
> >> >> channel clock, strangely routed.
> >> >>
> >> >> > More interestingly, I enabled test pattern directly in TCON to
> >> >> > eliminate
> >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> >> > pattern
> >> >> > on
> >> >> > HDMI screen was gone, which suggest that this gate influences
> >> >> > something
> >> >> > inside TCON.
> >> >> >
> >> >> > Another test I did was that I moved enable/disable gate code to
> >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >> >
> >> >> > I'll ask AW engineer what that gate actually does, but from what I
> >> >> > saw,
> >> >> > I
> >> >> > would say that most appropriate location to enable/disable TCON TOP
> >> >> > TV
> >> >> > TCON
> >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
> >> >> > any
> >> >> > TV
> >> >> > TCON is in use and enable appropriate gate. However, that doesn't
> >> >> > sound
> >> >> > right to me for some reason.
> >> >>
> >> >> If what I said above it true, then yes, the appropriate location to
> >> >> enable
> >> >> it is the TCON driver, but moreover, the representation of the clock
> >> >> tree
> >> >> should be fixed such that the TCON takes the clock from the TCON TOP
> >> >> as
> >> >> its
> >> >> channel/ module clock instead. That way you don't need this patch, but
> >> >> you'd add another for all the clock routing.
> >> >
> >> > Can you be more specific? I not sure what you mean here.
> >>
> >> For clock related properties in the device tree:
> >>
> >> &tcon_top {
> >>
> >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >>
> >> <&ccu CLK_TCON_TV0>,
> >> <&tve0>,
> >> <&ccu CLK_TCON_TV1>,
> >> <&tve1>;
> >>
> >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >>
> >> };
> >>
> >> &tcon_tv0 {
> >>
> >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> clock-names = "ahb", "tcon-ch1";
> >>
> >> };
> >>
> >> A diagram would look like:
> >> | This part is TCON TOP |
> >>
> >> v v
> >>
> >> CCU CLK_TCON_TV0 --|----\ |
> >>
> >> | mux ---- gate ----|-- TCON_TV0
> >>
> >> TVE0 --------------|----/ |
> >>
> >> And the same goes for TCON_TV1 and TVE1.
> >>
> >> The user manual is a bit lacking on how TVE outputs a clock though.
> >
> > I didn't yet received any response on HW details from AW till now, but I
> > would like to post new version of patches soon.
> >
> > While chaining like you described could be implemented easily, I don't
> > think it really represents HW as it is. Tests showed that these two
> > clocks are independent, otherwise register writes/reads wouldn't be
> > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
> > parent becase if it is not enabled, it simply won't work.
>
> AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
> is disabled, register accesses still work.
You're right, I just tested that.
> I'm saying that the TCON TOP
> gate is downstream from the TCON channel clock in the CCU. These are not
> related to the TCON bus clock in the CCU, which affects register access.
>
> Did Allwinner provide any information regarding the hierarchy of the clocks?
No reponse for now.
> > However, if everyone feels chaining is the best way to implement it, I'll
> > do it.
>
> I would like to get it right and match actual hardware. My proposal is
> based on my understanding from the diagrams in the user manual.
So for now, your explanation is the most reasonable. Should we go ahead and
implement your idea?
Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one TV
TCON instead of two of each kind. That means we will have hole in indices
(tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and different TCON-
TOP binding (no tcon_tv1 channel clock), but setup is exactly the same.
Best regard,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-21 15:35 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-21 15:35 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net>
wrote:
> > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
> >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >> >>
> >> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> >> >> > Hi,
> >> >> >
> >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
napisal(a):
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
> >> >> >> > order
> >> >> >> > to work.
> >> >> >> >
> >> >> >> > Add support for such TCONs.
> >> >> >> >
> >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> >> >> > ---
> >> >> >> >
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> >> > 2 files changed, 15 insertions(+)
> >> >> >> >
> >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> >> > 100644
> >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> >> >> >> > device
> >> >> >> > *dev,
> >> >> >> >
> >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> >> >> >> > return PTR_ERR(tcon->clk);
> >> >> >> >
> >> >> >> > }
> >> >> >> >
> >> >> >> > +
> >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> >> >> >> > clock\n");
> >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> >> > + }
> >> >> >> > +
> >> >> >>
> >> >> >> Is it required for the TCON itself to operate, or does the TCON
> >> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> >> >> functional?
> >> >> >>
> >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> >> >> particular
> >> >> >> device to actually be wired to another device. I'm not saying this
> >> >> >> isn't the case, but it would be a first.
> >> >> >
> >> >> > Documentation doesn't say much about that gate. I did few tests and
> >> >> > TCON
> >> >> > registers can be read and written even if TCON TOP TV TCON gate is
> >> >> > disabled. However, there is no image, as expected.
> >> >>
> >> >> The R40 manual does include it in the diagram, on page 504. There's
> >> >> also
> >> >> a
> >> >> mux to select whether the clock comes directly from the CCU or the TV
> >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> >> referring
> >> >> to
> >> >> here, in which case it is not a bus clock, but rather the TCON module
> >> >> or
> >> >> channel clock, strangely routed.
> >> >>
> >> >> > More interestingly, I enabled test pattern directly in TCON to
> >> >> > eliminate
> >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> >> > pattern
> >> >> > on
> >> >> > HDMI screen was gone, which suggest that this gate influences
> >> >> > something
> >> >> > inside TCON.
> >> >> >
> >> >> > Another test I did was that I moved enable/disable gate code to
> >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >> >
> >> >> > I'll ask AW engineer what that gate actually does, but from what I
> >> >> > saw,
> >> >> > I
> >> >> > would say that most appropriate location to enable/disable TCON TOP
> >> >> > TV
> >> >> > TCON
> >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
> >> >> > any
> >> >> > TV
> >> >> > TCON is in use and enable appropriate gate. However, that doesn't
> >> >> > sound
> >> >> > right to me for some reason.
> >> >>
> >> >> If what I said above it true, then yes, the appropriate location to
> >> >> enable
> >> >> it is the TCON driver, but moreover, the representation of the clock
> >> >> tree
> >> >> should be fixed such that the TCON takes the clock from the TCON TOP
> >> >> as
> >> >> its
> >> >> channel/ module clock instead. That way you don't need this patch, but
> >> >> you'd add another for all the clock routing.
> >> >
> >> > Can you be more specific? I not sure what you mean here.
> >>
> >> For clock related properties in the device tree:
> >>
> >> &tcon_top {
> >>
> >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >>
> >> <&ccu CLK_TCON_TV0>,
> >> <&tve0>,
> >> <&ccu CLK_TCON_TV1>,
> >> <&tve1>;
> >>
> >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >>
> >> };
> >>
> >> &tcon_tv0 {
> >>
> >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> clock-names = "ahb", "tcon-ch1";
> >>
> >> };
> >>
> >> A diagram would look like:
> >> | This part is TCON TOP |
> >>
> >> v v
> >>
> >> CCU CLK_TCON_TV0 --|----\ |
> >>
> >> | mux ---- gate ----|-- TCON_TV0
> >>
> >> TVE0 --------------|----/ |
> >>
> >> And the same goes for TCON_TV1 and TVE1.
> >>
> >> The user manual is a bit lacking on how TVE outputs a clock though.
> >
> > I didn't yet received any response on HW details from AW till now, but I
> > would like to post new version of patches soon.
> >
> > While chaining like you described could be implemented easily, I don't
> > think it really represents HW as it is. Tests showed that these two
> > clocks are independent, otherwise register writes/reads wouldn't be
> > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
> > parent becase if it is not enabled, it simply won't work.
>
> AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
> is disabled, register accesses still work.
You're right, I just tested that.
> I'm saying that the TCON TOP
> gate is downstream from the TCON channel clock in the CCU. These are not
> related to the TCON bus clock in the CCU, which affects register access.
>
> Did Allwinner provide any information regarding the hierarchy of the clocks?
No reponse for now.
> > However, if everyone feels chaining is the best way to implement it, I'll
> > do it.
>
> I would like to get it right and match actual hardware. My proposal is
> based on my understanding from the diagrams in the user manual.
So for now, your explanation is the most reasonable. Should we go ahead and
implement your idea?
Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one TV
TCON instead of two of each kind. That means we will have hole in indices
(tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and different TCON-
TOP binding (no tcon_tv1 channel clock), but setup is exactly the same.
Best regard,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
2018-06-21 15:35 ` Jernej Škrabec
(?)
(?)
@ 2018-06-24 19:52 ` Jernej Škrabec
-1 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-24 19:52 UTC (permalink / raw)
To: linux-sunxi
Cc: Chen-Yu Tsai, Maxime Ripard, Rob Herring, David Airlie,
Gustavo Padovan, Maarten Lankhorst, Sean Paul, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net>
>
> wrote:
> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> > >> <jernej.skrabec@siol.net>
> > >
> > > wrote:
> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
napisal(a):
> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> > >> >>
> > >> >> <jernej.skrabec@siol.net> wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>
> napisal(a):
> > >> >> >> Hi,
> > >> >> >>
> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
> > >> >> >> > in
> > >> >> >> > order
> > >> >> >> > to work.
> > >> >> >> >
> > >> >> >> > Add support for such TCONs.
> > >> >> >> >
> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > >> >> >> > ---
> > >> >> >> >
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> > >> >> >> > 2 files changed, 15 insertions(+)
> > >> >> >> >
> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> > >> >> >> > 08747fc3ee71..0afb5a94a414
> > >> >> >> > 100644
> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> > >> >> >> > device
> > >> >> >> > *dev,
> > >> >> >> >
> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > >> >> >> > return PTR_ERR(tcon->clk);
> > >> >> >> >
> > >> >> >> > }
> > >> >> >> >
> > >> >> >> > +
> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> > >> >> >> > clock\n");
> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > +
> > >> >> >>
> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
> > >> >> >> functional?
> > >> >> >>
> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> > >> >> >> particular
> > >> >> >> device to actually be wired to another device. I'm not saying
> > >> >> >> this
> > >> >> >> isn't the case, but it would be a first.
> > >> >> >
> > >> >> > Documentation doesn't say much about that gate. I did few tests
> > >> >> > and
> > >> >> > TCON
> > >> >> > registers can be read and written even if TCON TOP TV TCON gate is
> > >> >> > disabled. However, there is no image, as expected.
> > >> >>
> > >> >> The R40 manual does include it in the diagram, on page 504. There's
> > >> >> also
> > >> >> a
> > >> >> mux to select whether the clock comes directly from the CCU or the
> > >> >> TV
> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> > >> >> referring
> > >> >> to
> > >> >> here, in which case it is not a bus clock, but rather the TCON
> > >> >> module
> > >> >> or
> > >> >> channel clock, strangely routed.
> > >> >>
> > >> >> > More interestingly, I enabled test pattern directly in TCON to
> > >> >> > eliminate
> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> > >> >> > pattern
> > >> >> > on
> > >> >> > HDMI screen was gone, which suggest that this gate influences
> > >> >> > something
> > >> >> > inside TCON.
> > >> >> >
> > >> >> > Another test I did was that I moved enable/disable gate code to
> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> > >> >> >
> > >> >> > I'll ask AW engineer what that gate actually does, but from what I
> > >> >> > saw,
> > >> >> > I
> > >> >> > would say that most appropriate location to enable/disable TCON
> > >> >> > TOP
> > >> >> > TV
> > >> >> > TCON
> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
> > >> >> > any
> > >> >> > TV
> > >> >> > TCON is in use and enable appropriate gate. However, that doesn't
> > >> >> > sound
> > >> >> > right to me for some reason.
> > >> >>
> > >> >> If what I said above it true, then yes, the appropriate location to
> > >> >> enable
> > >> >> it is the TCON driver, but moreover, the representation of the clock
> > >> >> tree
> > >> >> should be fixed such that the TCON takes the clock from the TCON TOP
> > >> >> as
> > >> >> its
> > >> >> channel/ module clock instead. That way you don't need this patch,
> > >> >> but
> > >> >> you'd add another for all the clock routing.
> > >> >
> > >> > Can you be more specific? I not sure what you mean here.
> > >>
> > >> For clock related properties in the device tree:
> > >>
> > >> &tcon_top {
> > >>
> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> > >>
> > >> <&ccu CLK_TCON_TV0>,
> > >> <&tve0>,
> > >> <&ccu CLK_TCON_TV1>,
> > >> <&tve1>;
> > >>
> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> > >>
> > >> };
> > >>
> > >> &tcon_tv0 {
> > >>
> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> > >> clock-names = "ahb", "tcon-ch1";
> > >>
> > >> };
> > >>
> > >> A diagram would look like:
> > >> | This part is TCON TOP |
> > >>
> > >> v v
> > >>
> > >> CCU CLK_TCON_TV0 --|----\ |
> > >>
> > >> | mux ---- gate ----|-- TCON_TV0
> > >>
> > >> TVE0 --------------|----/ |
> > >>
> > >> And the same goes for TCON_TV1 and TVE1.
> > >>
> > >> The user manual is a bit lacking on how TVE outputs a clock though.
> > >
> > > I didn't yet received any response on HW details from AW till now, but I
> > > would like to post new version of patches soon.
> > >
> > > While chaining like you described could be implemented easily, I don't
> > > think it really represents HW as it is. Tests showed that these two
> > > clocks are independent, otherwise register writes/reads wouldn't be
> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
> > > parent becase if it is not enabled, it simply won't work.
> >
> > AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
> > is disabled, register accesses still work.
>
> You're right, I just tested that.
>
> > I'm saying that the TCON TOP
> > gate is downstream from the TCON channel clock in the CCU. These are not
> > related to the TCON bus clock in the CCU, which affects register access.
> >
> > Did Allwinner provide any information regarding the hierarchy of the
> > clocks?
> No reponse for now.
>
> > > However, if everyone feels chaining is the best way to implement it,
> > > I'll
> > > do it.
> >
> > I would like to get it right and match actual hardware. My proposal is
> > based on my understanding from the diagrams in the user manual.
>
> So for now, your explanation is the most reasonable. Should we go ahead and
> implement your idea?
>
> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one
> TV TCON instead of two of each kind. That means we will have hole in
> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> exactly the same.
I just noticed issue with this proposal. If we have following clock chain for
HDMI, everythings is ok:
TCON-TV0 -> TCON-TOP-TV0
TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock and
everything works.
However, when TVE will be configured, it would look like this:
TVE0 -> TCON-TOP-TV0
TVE driver will set TVE0 clock to 216 MHz and TCON TV would set TCON-TOP-TV0
rate which in turn sets TVE0 clock to something like 13.5 MHz (or whatever is
the right clock rate for PAL and NTSC). As you can see, same clock is set to
two different rates by two different drivers.
It *might* still work, since encoders set clock rate after TCON (at least that
is my experience for HDMI pipeline), but that is still wrong.
To overcome above issue, I would stick to original proposal with additional
clock specified in TCON TV DT node. That way TCON driver would always set
clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere with
setting clock rate, because TCON-TV0 clock would be decoupled in TCON-TOP mux.
What do you think?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-24 19:52 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-24 19:52 UTC (permalink / raw)
To: linux-arm-kernel
Dne ?etrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej ?krabec napisal(a):
> Dne ?etrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej ?krabec <jernej.skrabec@siol.net>
>
> wrote:
> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec
> > >> <jernej.skrabec@siol.net>
> > >
> > > wrote:
> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
napisal(a):
> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
> > >> >>
> > >> >> <jernej.skrabec@siol.net> wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>
> napisal(a):
> > >> >> >> Hi,
> > >> >> >>
> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
> > >> >> >> > in
> > >> >> >> > order
> > >> >> >> > to work.
> > >> >> >> >
> > >> >> >> > Add support for such TCONs.
> > >> >> >> >
> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > >> >> >> > ---
> > >> >> >> >
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> > >> >> >> > 2 files changed, 15 insertions(+)
> > >> >> >> >
> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> > >> >> >> > 08747fc3ee71..0afb5a94a414
> > >> >> >> > 100644
> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> > >> >> >> > device
> > >> >> >> > *dev,
> > >> >> >> >
> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > >> >> >> > return PTR_ERR(tcon->clk);
> > >> >> >> >
> > >> >> >> > }
> > >> >> >> >
> > >> >> >> > +
> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> > >> >> >> > clock\n");
> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > +
> > >> >> >>
> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
> > >> >> >> functional?
> > >> >> >>
> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> > >> >> >> particular
> > >> >> >> device to actually be wired to another device. I'm not saying
> > >> >> >> this
> > >> >> >> isn't the case, but it would be a first.
> > >> >> >
> > >> >> > Documentation doesn't say much about that gate. I did few tests
> > >> >> > and
> > >> >> > TCON
> > >> >> > registers can be read and written even if TCON TOP TV TCON gate is
> > >> >> > disabled. However, there is no image, as expected.
> > >> >>
> > >> >> The R40 manual does include it in the diagram, on page 504. There's
> > >> >> also
> > >> >> a
> > >> >> mux to select whether the clock comes directly from the CCU or the
> > >> >> TV
> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> > >> >> referring
> > >> >> to
> > >> >> here, in which case it is not a bus clock, but rather the TCON
> > >> >> module
> > >> >> or
> > >> >> channel clock, strangely routed.
> > >> >>
> > >> >> > More interestingly, I enabled test pattern directly in TCON to
> > >> >> > eliminate
> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> > >> >> > pattern
> > >> >> > on
> > >> >> > HDMI screen was gone, which suggest that this gate influences
> > >> >> > something
> > >> >> > inside TCON.
> > >> >> >
> > >> >> > Another test I did was that I moved enable/disable gate code to
> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> > >> >> >
> > >> >> > I'll ask AW engineer what that gate actually does, but from what I
> > >> >> > saw,
> > >> >> > I
> > >> >> > would say that most appropriate location to enable/disable TCON
> > >> >> > TOP
> > >> >> > TV
> > >> >> > TCON
> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
> > >> >> > any
> > >> >> > TV
> > >> >> > TCON is in use and enable appropriate gate. However, that doesn't
> > >> >> > sound
> > >> >> > right to me for some reason.
> > >> >>
> > >> >> If what I said above it true, then yes, the appropriate location to
> > >> >> enable
> > >> >> it is the TCON driver, but moreover, the representation of the clock
> > >> >> tree
> > >> >> should be fixed such that the TCON takes the clock from the TCON TOP
> > >> >> as
> > >> >> its
> > >> >> channel/ module clock instead. That way you don't need this patch,
> > >> >> but
> > >> >> you'd add another for all the clock routing.
> > >> >
> > >> > Can you be more specific? I not sure what you mean here.
> > >>
> > >> For clock related properties in the device tree:
> > >>
> > >> &tcon_top {
> > >>
> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> > >>
> > >> <&ccu CLK_TCON_TV0>,
> > >> <&tve0>,
> > >> <&ccu CLK_TCON_TV1>,
> > >> <&tve1>;
> > >>
> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> > >>
> > >> };
> > >>
> > >> &tcon_tv0 {
> > >>
> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> > >> clock-names = "ahb", "tcon-ch1";
> > >>
> > >> };
> > >>
> > >> A diagram would look like:
> > >> | This part is TCON TOP |
> > >>
> > >> v v
> > >>
> > >> CCU CLK_TCON_TV0 --|----\ |
> > >>
> > >> | mux ---- gate ----|-- TCON_TV0
> > >>
> > >> TVE0 --------------|----/ |
> > >>
> > >> And the same goes for TCON_TV1 and TVE1.
> > >>
> > >> The user manual is a bit lacking on how TVE outputs a clock though.
> > >
> > > I didn't yet received any response on HW details from AW till now, but I
> > > would like to post new version of patches soon.
> > >
> > > While chaining like you described could be implemented easily, I don't
> > > think it really represents HW as it is. Tests showed that these two
> > > clocks are independent, otherwise register writes/reads wouldn't be
> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
> > > parent becase if it is not enabled, it simply won't work.
> >
> > AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
> > is disabled, register accesses still work.
>
> You're right, I just tested that.
>
> > I'm saying that the TCON TOP
> > gate is downstream from the TCON channel clock in the CCU. These are not
> > related to the TCON bus clock in the CCU, which affects register access.
> >
> > Did Allwinner provide any information regarding the hierarchy of the
> > clocks?
> No reponse for now.
>
> > > However, if everyone feels chaining is the best way to implement it,
> > > I'll
> > > do it.
> >
> > I would like to get it right and match actual hardware. My proposal is
> > based on my understanding from the diagrams in the user manual.
>
> So for now, your explanation is the most reasonable. Should we go ahead and
> implement your idea?
>
> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one
> TV TCON instead of two of each kind. That means we will have hole in
> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> exactly the same.
I just noticed issue with this proposal. If we have following clock chain for
HDMI, everythings is ok:
TCON-TV0 -> TCON-TOP-TV0
TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock and
everything works.
However, when TVE will be configured, it would look like this:
TVE0 -> TCON-TOP-TV0
TVE driver will set TVE0 clock to 216 MHz and TCON TV would set TCON-TOP-TV0
rate which in turn sets TVE0 clock to something like 13.5 MHz (or whatever is
the right clock rate for PAL and NTSC). As you can see, same clock is set to
two different rates by two different drivers.
It *might* still work, since encoders set clock rate after TCON (at least that
is my experience for HDMI pipeline), but that is still wrong.
To overcome above issue, I would stick to original proposal with additional
clock specified in TCON TV DT node. That way TCON driver would always set
clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere with
setting clock rate, because TCON-TV0 clock would be decoupled in TCON-TOP mux.
What do you think?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-24 19:52 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-24 19:52 UTC (permalink / raw)
To: linux-sunxi
Cc: Chen-Yu Tsai, Maxime Ripard, Rob Herring, David Airlie,
Gustavo Padovan, Maarten Lankhorst, Sean Paul, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne =C4=8Detrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej =C5=A0krabec na=
pisal(a):
> Dne =C4=8Detrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal=
(a):
> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej =C5=A0krabec <jernej.skrabec@si=
ol.net>
>=20
> wrote:
> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a=
):
> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej =C5=A0krabec
> > >> <jernej.skrabec@siol.net>
> > >=20
> > > wrote:
> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai=20
napisal(a):
> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej =C5=A0krabec
> > >> >>=20
> > >> >> <jernej.skrabec@siol.net> wrote:
> > >> >> > Hi,
> > >> >> >=20
> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>=20
> napisal(a):
> > >> >> >> Hi,
> > >> >> >>=20
> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
> > >> >> >> > in
> > >> >> >> > order
> > >> >> >> > to work.
> > >> >> >> >=20
> > >> >> >> > Add support for such TCONs.
> > >> >> >> >=20
> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > >> >> >> > ---
> > >> >> >> >=20
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> > >> >> >> > 2 files changed, 15 insertions(+)
> > >> >> >> >=20
> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> > >> >> >> > 08747fc3ee71..0afb5a94a414
> > >> >> >> > 100644
> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> > >> >> >> > device
> > >> >> >> > *dev,
> > >> >> >> >=20
> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n"=
);
> > >> >> >> > return PTR_ERR(tcon->clk);
> > >> >> >> > =20
> > >> >> >> > }
> > >> >> >> >=20
> > >> >> >> > +
> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> > >> >> >> > + tcon->top_clk =3D devm_clk_get(dev, "tcon-top");
> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP =
bus
> > >> >> >> > clock\n");
> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > +
> > >> >> >>=20
> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
> > >> >> >> functional?
> > >> >> >>=20
> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> > >> >> >> particular
> > >> >> >> device to actually be wired to another device. I'm not saying
> > >> >> >> this
> > >> >> >> isn't the case, but it would be a first.
> > >> >> >=20
> > >> >> > Documentation doesn't say much about that gate. I did few tests
> > >> >> > and
> > >> >> > TCON
> > >> >> > registers can be read and written even if TCON TOP TV TCON gate=
is
> > >> >> > disabled. However, there is no image, as expected.
> > >> >>=20
> > >> >> The R40 manual does include it in the diagram, on page 504. There=
's
> > >> >> also
> > >> >> a
> > >> >> mux to select whether the clock comes directly from the CCU or the
> > >> >> TV
> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> > >> >> referring
> > >> >> to
> > >> >> here, in which case it is not a bus clock, but rather the TCON
> > >> >> module
> > >> >> or
> > >> >> channel clock, strangely routed.
> > >> >>=20
> > >> >> > More interestingly, I enabled test pattern directly in TCON to
> > >> >> > eliminate
> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> > >> >> > pattern
> > >> >> > on
> > >> >> > HDMI screen was gone, which suggest that this gate influences
> > >> >> > something
> > >> >> > inside TCON.
> > >> >> >=20
> > >> >> > Another test I did was that I moved enable/disable gate code to
> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> > >> >> >=20
> > >> >> > I'll ask AW engineer what that gate actually does, but from wha=
t I
> > >> >> > saw,
> > >> >> > I
> > >> >> > would say that most appropriate location to enable/disable TCON
> > >> >> > TOP
> > >> >> > TV
> > >> >> > TCON
> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check=
if
> > >> >> > any
> > >> >> > TV
> > >> >> > TCON is in use and enable appropriate gate. However, that doesn=
't
> > >> >> > sound
> > >> >> > right to me for some reason.
> > >> >>=20
> > >> >> If what I said above it true, then yes, the appropriate location =
to
> > >> >> enable
> > >> >> it is the TCON driver, but moreover, the representation of the cl=
ock
> > >> >> tree
> > >> >> should be fixed such that the TCON takes the clock from the TCON =
TOP
> > >> >> as
> > >> >> its
> > >> >> channel/ module clock instead. That way you don't need this patch,
> > >> >> but
> > >> >> you'd add another for all the clock routing.
> > >> >=20
> > >> > Can you be more specific? I not sure what you mean here.
> > >>=20
> > >> For clock related properties in the device tree:
> > >>=20
> > >> &tcon_top {
> > >>=20
> > >> clocks =3D <&ccu CLK_BUS_TCON_TOP>,
> > >> =20
> > >> <&ccu CLK_TCON_TV0>,
> > >> <&tve0>,
> > >> <&ccu CLK_TCON_TV1>,
> > >> <&tve1>;
> > >> =20
> > >> clock-names =3D "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> > >> clock-output-names =3D "tcon-top-tv0", "tcon-top-tv1";
> > >>=20
> > >> };
> > >>=20
> > >> &tcon_tv0 {
> > >>=20
> > >> clocks =3D <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> > >> clock-names =3D "ahb", "tcon-ch1";
> > >>=20
> > >> };
> > >>=20
> > >> A diagram would look like:
> > >> | This part is TCON TOP |
> > >> =20
> > >> v v
> > >>=20
> > >> CCU CLK_TCON_TV0 --|----\ |
> > >>=20
> > >> | mux ---- gate ----|-- TCON_TV0
> > >>=20
> > >> TVE0 --------------|----/ |
> > >>=20
> > >> And the same goes for TCON_TV1 and TVE1.
> > >>=20
> > >> The user manual is a bit lacking on how TVE outputs a clock though.
> > >=20
> > > I didn't yet received any response on HW details from AW till now, bu=
t I
> > > would like to post new version of patches soon.
> > >=20
> > > While chaining like you described could be implemented easily, I don't
> > > think it really represents HW as it is. Tests showed that these two
> > > clocks are independent, otherwise register writes/reads wouldn't be
> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
> > > parent becase if it is not enabled, it simply won't work.
> >=20
> > AFAIK with the TCONs, even when the TCON channel clock (not the bus clo=
ck)
> > is disabled, register accesses still work.
>=20
> You're right, I just tested that.
>=20
> > I'm saying that the TCON TOP
> > gate is downstream from the TCON channel clock in the CCU. These are not
> > related to the TCON bus clock in the CCU, which affects register access.
> >=20
> > Did Allwinner provide any information regarding the hierarchy of the
> > clocks?
> No reponse for now.
>=20
> > > However, if everyone feels chaining is the best way to implement it,
> > > I'll
> > > do it.
> >=20
> > I would like to get it right and match actual hardware. My proposal is
> > based on my understanding from the diagrams in the user manual.
>=20
> So for now, your explanation is the most reasonable. Should we go ahead a=
nd
> implement your idea?
>=20
> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one
> TV TCON instead of two of each kind. That means we will have hole in
> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> exactly the same.
I just noticed issue with this proposal. If we have following clock chain f=
or=20
HDMI, everythings is ok:
TCON-TV0 -> TCON-TOP-TV0
TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock and=
=20
everything works.
However, when TVE will be configured, it would look like this:
TVE0 -> TCON-TOP-TV0
TVE driver will set TVE0 clock to 216 MHz and TCON TV would set TCON-TOP-TV=
0=20
rate which in turn sets TVE0 clock to something like 13.5 MHz (or whatever =
is=20
the right clock rate for PAL and NTSC). As you can see, same clock is set t=
o=20
two different rates by two different drivers.
It *might* still work, since encoders set clock rate after TCON (at least t=
hat=20
is my experience for HDMI pipeline), but that is still wrong.
To overcome above issue, I would stick to original proposal with additional=
=20
clock specified in TCON TV DT node. That way TCON driver would always set=20
clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere w=
ith=20
setting clock rate, because TCON-TV0 clock would be decoupled in TCON-TOP m=
ux.
What do you think?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-24 19:52 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-24 19:52 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: Chen-Yu Tsai, Maxime Ripard, Rob Herring, David Airlie,
Gustavo Padovan, Maarten Lankhorst, Sean Paul, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net>
>
> wrote:
> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> > >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> > >
> > > wrote:
> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
napisal(a):
> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> > >> >>
> > >> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> > >> >> > Hi,
> > >> >> >
> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>
> napisal(a):
> > >> >> >> Hi,
> > >> >> >>
> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
> > >> >> >> > in
> > >> >> >> > order
> > >> >> >> > to work.
> > >> >> >> >
> > >> >> >> > Add support for such TCONs.
> > >> >> >> >
> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> > >> >> >> > ---
> > >> >> >> >
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> > >> >> >> > 2 files changed, 15 insertions(+)
> > >> >> >> >
> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> > >> >> >> > 08747fc3ee71..0afb5a94a414
> > >> >> >> > 100644
> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
> > >> >> >> > device
> > >> >> >> > *dev,
> > >> >> >> >
> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
> > >> >> >> > return PTR_ERR(tcon->clk);
> > >> >> >> >
> > >> >> >> > }
> > >> >> >> >
> > >> >> >> > +
> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
> > >> >> >> > clock\n");
> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> > >> >> >> > + }
> > >> >> >> > +
> > >> >> >>
> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
> > >> >> >> functional?
> > >> >> >>
> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> > >> >> >> particular
> > >> >> >> device to actually be wired to another device. I'm not saying
> > >> >> >> this
> > >> >> >> isn't the case, but it would be a first.
> > >> >> >
> > >> >> > Documentation doesn't say much about that gate. I did few tests
> > >> >> > and
> > >> >> > TCON
> > >> >> > registers can be read and written even if TCON TOP TV TCON gate is
> > >> >> > disabled. However, there is no image, as expected.
> > >> >>
> > >> >> The R40 manual does include it in the diagram, on page 504. There's
> > >> >> also
> > >> >> a
> > >> >> mux to select whether the clock comes directly from the CCU or the
> > >> >> TV
> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> > >> >> referring
> > >> >> to
> > >> >> here, in which case it is not a bus clock, but rather the TCON
> > >> >> module
> > >> >> or
> > >> >> channel clock, strangely routed.
> > >> >>
> > >> >> > More interestingly, I enabled test pattern directly in TCON to
> > >> >> > eliminate
> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> > >> >> > pattern
> > >> >> > on
> > >> >> > HDMI screen was gone, which suggest that this gate influences
> > >> >> > something
> > >> >> > inside TCON.
> > >> >> >
> > >> >> > Another test I did was that I moved enable/disable gate code to
> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> > >> >> >
> > >> >> > I'll ask AW engineer what that gate actually does, but from what I
> > >> >> > saw,
> > >> >> > I
> > >> >> > would say that most appropriate location to enable/disable TCON
> > >> >> > TOP
> > >> >> > TV
> > >> >> > TCON
> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
> > >> >> > any
> > >> >> > TV
> > >> >> > TCON is in use and enable appropriate gate. However, that doesn't
> > >> >> > sound
> > >> >> > right to me for some reason.
> > >> >>
> > >> >> If what I said above it true, then yes, the appropriate location to
> > >> >> enable
> > >> >> it is the TCON driver, but moreover, the representation of the clock
> > >> >> tree
> > >> >> should be fixed such that the TCON takes the clock from the TCON TOP
> > >> >> as
> > >> >> its
> > >> >> channel/ module clock instead. That way you don't need this patch,
> > >> >> but
> > >> >> you'd add another for all the clock routing.
> > >> >
> > >> > Can you be more specific? I not sure what you mean here.
> > >>
> > >> For clock related properties in the device tree:
> > >>
> > >> &tcon_top {
> > >>
> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> > >>
> > >> <&ccu CLK_TCON_TV0>,
> > >> <&tve0>,
> > >> <&ccu CLK_TCON_TV1>,
> > >> <&tve1>;
> > >>
> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> > >>
> > >> };
> > >>
> > >> &tcon_tv0 {
> > >>
> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> > >> clock-names = "ahb", "tcon-ch1";
> > >>
> > >> };
> > >>
> > >> A diagram would look like:
> > >> | This part is TCON TOP |
> > >>
> > >> v v
> > >>
> > >> CCU CLK_TCON_TV0 --|----\ |
> > >>
> > >> | mux ---- gate ----|-- TCON_TV0
> > >>
> > >> TVE0 --------------|----/ |
> > >>
> > >> And the same goes for TCON_TV1 and TVE1.
> > >>
> > >> The user manual is a bit lacking on how TVE outputs a clock though.
> > >
> > > I didn't yet received any response on HW details from AW till now, but I
> > > would like to post new version of patches soon.
> > >
> > > While chaining like you described could be implemented easily, I don't
> > > think it really represents HW as it is. Tests showed that these two
> > > clocks are independent, otherwise register writes/reads wouldn't be
> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
> > > parent becase if it is not enabled, it simply won't work.
> >
> > AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
> > is disabled, register accesses still work.
>
> You're right, I just tested that.
>
> > I'm saying that the TCON TOP
> > gate is downstream from the TCON channel clock in the CCU. These are not
> > related to the TCON bus clock in the CCU, which affects register access.
> >
> > Did Allwinner provide any information regarding the hierarchy of the
> > clocks?
> No reponse for now.
>
> > > However, if everyone feels chaining is the best way to implement it,
> > > I'll
> > > do it.
> >
> > I would like to get it right and match actual hardware. My proposal is
> > based on my understanding from the diagrams in the user manual.
>
> So for now, your explanation is the most reasonable. Should we go ahead and
> implement your idea?
>
> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one
> TV TCON instead of two of each kind. That means we will have hole in
> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> exactly the same.
I just noticed issue with this proposal. If we have following clock chain for
HDMI, everythings is ok:
TCON-TV0 -> TCON-TOP-TV0
TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock and
everything works.
However, when TVE will be configured, it would look like this:
TVE0 -> TCON-TOP-TV0
TVE driver will set TVE0 clock to 216 MHz and TCON TV would set TCON-TOP-TV0
rate which in turn sets TVE0 clock to something like 13.5 MHz (or whatever is
the right clock rate for PAL and NTSC). As you can see, same clock is set to
two different rates by two different drivers.
It *might* still work, since encoders set clock rate after TCON (at least that
is my experience for HDMI pipeline), but that is still wrong.
To overcome above issue, I would stick to original proposal with additional
clock specified in TCON TV DT node. That way TCON driver would always set
clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere with
setting clock rate, because TCON-TV0 clock would be decoupled in TCON-TOP mux.
What do you think?
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
2018-06-24 19:52 ` Jernej Škrabec
(?)
@ 2018-06-25 3:51 ` Chen-Yu Tsai
-1 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-25 3:51 UTC (permalink / raw)
To: Jernej Škrabec
Cc: linux-sunxi, Maxime Ripard, Rob Herring, David Airlie,
Gustavo Padovan, Maarten Lankhorst, Sean Paul, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk
On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
<jernej.skrabec@gmail.com> wrote:
> Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
>> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
>> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net>
>>
>> wrote:
>> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
>> > >> <jernej.skrabec@siol.net>
>> > >
>> > > wrote:
>> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> napisal(a):
>> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> > >> >>
>> > >> >> <jernej.skrabec@siol.net> wrote:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>>
>> napisal(a):
>> > >> >> >> Hi,
>> > >> >> >>
>> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
>> > >> >> >> > in
>> > >> >> >> > order
>> > >> >> >> > to work.
>> > >> >> >> >
>> > >> >> >> > Add support for such TCONs.
>> > >> >> >> >
>> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> > >> >> >> > ---
>> > >> >> >> >
>> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> > >> >> >> > 2 files changed, 15 insertions(+)
>> > >> >> >> >
>> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> > >> >> >> > 08747fc3ee71..0afb5a94a414
>> > >> >> >> > 100644
>> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
>> > >> >> >> > device
>> > >> >> >> > *dev,
>> > >> >> >> >
>> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > >> >> >> > return PTR_ERR(tcon->clk);
>> > >> >> >> >
>> > >> >> >> > }
>> > >> >> >> >
>> > >> >> >> > +
>> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> > >> >> >> > clock\n");
>> > >> >> >> > + return PTR_ERR(tcon->top_clk);
>> > >> >> >> > + }
>> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
>> > >> >> >> > + }
>> > >> >> >> > +
>> > >> >> >>
>> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
>> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
>> > >> >> >> functional?
>> > >> >> >>
>> > >> >> >> I find it quite odd to have a clock that isn't meant for a
>> > >> >> >> particular
>> > >> >> >> device to actually be wired to another device. I'm not saying
>> > >> >> >> this
>> > >> >> >> isn't the case, but it would be a first.
>> > >> >> >
>> > >> >> > Documentation doesn't say much about that gate. I did few tests
>> > >> >> > and
>> > >> >> > TCON
>> > >> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> > >> >> > disabled. However, there is no image, as expected.
>> > >> >>
>> > >> >> The R40 manual does include it in the diagram, on page 504. There's
>> > >> >> also
>> > >> >> a
>> > >> >> mux to select whether the clock comes directly from the CCU or the
>> > >> >> TV
>> > >> >> encoder (a feedback mode?). I assume this is the gate you are
>> > >> >> referring
>> > >> >> to
>> > >> >> here, in which case it is not a bus clock, but rather the TCON
>> > >> >> module
>> > >> >> or
>> > >> >> channel clock, strangely routed.
>> > >> >>
>> > >> >> > More interestingly, I enabled test pattern directly in TCON to
>> > >> >> > eliminate
>> > >> >> > influence of the mixer. As soon as I disabled that gate, test
>> > >> >> > pattern
>> > >> >> > on
>> > >> >> > HDMI screen was gone, which suggest that this gate influences
>> > >> >> > something
>> > >> >> > inside TCON.
>> > >> >> >
>> > >> >> > Another test I did was that I moved enable/disable gate code to
>> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> > >> >> >
>> > >> >> > I'll ask AW engineer what that gate actually does, but from what I
>> > >> >> > saw,
>> > >> >> > I
>> > >> >> > would say that most appropriate location to enable/disable TCON
>> > >> >> > TOP
>> > >> >> > TV
>> > >> >> > TCON
>> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
>> > >> >> > any
>> > >> >> > TV
>> > >> >> > TCON is in use and enable appropriate gate. However, that doesn't
>> > >> >> > sound
>> > >> >> > right to me for some reason.
>> > >> >>
>> > >> >> If what I said above it true, then yes, the appropriate location to
>> > >> >> enable
>> > >> >> it is the TCON driver, but moreover, the representation of the clock
>> > >> >> tree
>> > >> >> should be fixed such that the TCON takes the clock from the TCON TOP
>> > >> >> as
>> > >> >> its
>> > >> >> channel/ module clock instead. That way you don't need this patch,
>> > >> >> but
>> > >> >> you'd add another for all the clock routing.
>> > >> >
>> > >> > Can you be more specific? I not sure what you mean here.
>> > >>
>> > >> For clock related properties in the device tree:
>> > >>
>> > >> &tcon_top {
>> > >>
>> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> > >>
>> > >> <&ccu CLK_TCON_TV0>,
>> > >> <&tve0>,
>> > >> <&ccu CLK_TCON_TV1>,
>> > >> <&tve1>;
>> > >>
>> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> > >>
>> > >> };
>> > >>
>> > >> &tcon_tv0 {
>> > >>
>> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> > >> clock-names = "ahb", "tcon-ch1";
>> > >>
>> > >> };
>> > >>
>> > >> A diagram would look like:
>> > >> | This part is TCON TOP |
>> > >>
>> > >> v v
>> > >>
>> > >> CCU CLK_TCON_TV0 --|----\ |
>> > >>
>> > >> | mux ---- gate ----|-- TCON_TV0
>> > >>
>> > >> TVE0 --------------|----/ |
>> > >>
>> > >> And the same goes for TCON_TV1 and TVE1.
>> > >>
>> > >> The user manual is a bit lacking on how TVE outputs a clock though.
>> > >
>> > > I didn't yet received any response on HW details from AW till now, but I
>> > > would like to post new version of patches soon.
>> > >
>> > > While chaining like you described could be implemented easily, I don't
>> > > think it really represents HW as it is. Tests showed that these two
>> > > clocks are independent, otherwise register writes/reads wouldn't be
>> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
>> > > parent becase if it is not enabled, it simply won't work.
>> >
>> > AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
>> > is disabled, register accesses still work.
>>
>> You're right, I just tested that.
>>
>> > I'm saying that the TCON TOP
>> > gate is downstream from the TCON channel clock in the CCU. These are not
>> > related to the TCON bus clock in the CCU, which affects register access.
>> >
>> > Did Allwinner provide any information regarding the hierarchy of the
>> > clocks?
>> No reponse for now.
>>
>> > > However, if everyone feels chaining is the best way to implement it,
>> > > I'll
>> > > do it.
>> >
>> > I would like to get it right and match actual hardware. My proposal is
>> > based on my understanding from the diagrams in the user manual.
>>
>> So for now, your explanation is the most reasonable. Should we go ahead and
>> implement your idea?
>>
>> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one
>> TV TCON instead of two of each kind. That means we will have hole in
>> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
>> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
>> exactly the same.
>
> I just noticed issue with this proposal. If we have following clock chain for
> HDMI, everythings is ok:
>
> TCON-TV0 -> TCON-TOP-TV0
>
> TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock and
> everything works.
>
> However, when TVE will be configured, it would look like this:
>
> TVE0 -> TCON-TOP-TV0
>
> TVE driver will set TVE0 clock to 216 MHz and TCON TV would set TCON-TOP-TV0
> rate which in turn sets TVE0 clock to something like 13.5 MHz (or whatever is
> the right clock rate for PAL and NTSC). As you can see, same clock is set to
> two different rates by two different drivers.
>
> It *might* still work, since encoders set clock rate after TCON (at least that
> is my experience for HDMI pipeline), but that is still wrong.
>
> To overcome above issue, I would stick to original proposal with additional
> clock specified in TCON TV DT node. That way TCON driver would always set
> clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere with
> setting clock rate, because TCON-TV0 clock would be decoupled in TCON-TOP mux.
>
> What do you think?
I think this is the wrong representation, and worse, you are trying to work
around software issues with it.
So to confirm some details, the TVE expects 216 MHz clock, and it expects the
TCON to run and output data at 216 MHz as well. Is that correct?
Would any settings for the TCON differ between when HDMI or TVE is used?
Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt it.
It might be expecting 297 MHz for PC resolutions.
I think these kinds of quirks should be handled in the software, instead of
being papered over.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 3:51 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-25 3:51 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jun 25, 2018 at 3:52 AM, Jernej ?krabec
<jernej.skrabec@gmail.com> wrote:
> Dne ?etrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej ?krabec napisal(a):
>> Dne ?etrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
>> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej ?krabec <jernej.skrabec@siol.net>
>>
>> wrote:
>> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec
>> > >> <jernej.skrabec@siol.net>
>> > >
>> > > wrote:
>> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> napisal(a):
>> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
>> > >> >>
>> > >> >> <jernej.skrabec@siol.net> wrote:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>>
>> napisal(a):
>> > >> >> >> Hi,
>> > >> >> >>
>> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
>> > >> >> >> > in
>> > >> >> >> > order
>> > >> >> >> > to work.
>> > >> >> >> >
>> > >> >> >> > Add support for such TCONs.
>> > >> >> >> >
>> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> > >> >> >> > ---
>> > >> >> >> >
>> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> > >> >> >> > 2 files changed, 15 insertions(+)
>> > >> >> >> >
>> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> > >> >> >> > 08747fc3ee71..0afb5a94a414
>> > >> >> >> > 100644
>> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
>> > >> >> >> > device
>> > >> >> >> > *dev,
>> > >> >> >> >
>> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > >> >> >> > return PTR_ERR(tcon->clk);
>> > >> >> >> >
>> > >> >> >> > }
>> > >> >> >> >
>> > >> >> >> > +
>> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> > >> >> >> > clock\n");
>> > >> >> >> > + return PTR_ERR(tcon->top_clk);
>> > >> >> >> > + }
>> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
>> > >> >> >> > + }
>> > >> >> >> > +
>> > >> >> >>
>> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
>> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
>> > >> >> >> functional?
>> > >> >> >>
>> > >> >> >> I find it quite odd to have a clock that isn't meant for a
>> > >> >> >> particular
>> > >> >> >> device to actually be wired to another device. I'm not saying
>> > >> >> >> this
>> > >> >> >> isn't the case, but it would be a first.
>> > >> >> >
>> > >> >> > Documentation doesn't say much about that gate. I did few tests
>> > >> >> > and
>> > >> >> > TCON
>> > >> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> > >> >> > disabled. However, there is no image, as expected.
>> > >> >>
>> > >> >> The R40 manual does include it in the diagram, on page 504. There's
>> > >> >> also
>> > >> >> a
>> > >> >> mux to select whether the clock comes directly from the CCU or the
>> > >> >> TV
>> > >> >> encoder (a feedback mode?). I assume this is the gate you are
>> > >> >> referring
>> > >> >> to
>> > >> >> here, in which case it is not a bus clock, but rather the TCON
>> > >> >> module
>> > >> >> or
>> > >> >> channel clock, strangely routed.
>> > >> >>
>> > >> >> > More interestingly, I enabled test pattern directly in TCON to
>> > >> >> > eliminate
>> > >> >> > influence of the mixer. As soon as I disabled that gate, test
>> > >> >> > pattern
>> > >> >> > on
>> > >> >> > HDMI screen was gone, which suggest that this gate influences
>> > >> >> > something
>> > >> >> > inside TCON.
>> > >> >> >
>> > >> >> > Another test I did was that I moved enable/disable gate code to
>> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> > >> >> >
>> > >> >> > I'll ask AW engineer what that gate actually does, but from what I
>> > >> >> > saw,
>> > >> >> > I
>> > >> >> > would say that most appropriate location to enable/disable TCON
>> > >> >> > TOP
>> > >> >> > TV
>> > >> >> > TCON
>> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
>> > >> >> > any
>> > >> >> > TV
>> > >> >> > TCON is in use and enable appropriate gate. However, that doesn't
>> > >> >> > sound
>> > >> >> > right to me for some reason.
>> > >> >>
>> > >> >> If what I said above it true, then yes, the appropriate location to
>> > >> >> enable
>> > >> >> it is the TCON driver, but moreover, the representation of the clock
>> > >> >> tree
>> > >> >> should be fixed such that the TCON takes the clock from the TCON TOP
>> > >> >> as
>> > >> >> its
>> > >> >> channel/ module clock instead. That way you don't need this patch,
>> > >> >> but
>> > >> >> you'd add another for all the clock routing.
>> > >> >
>> > >> > Can you be more specific? I not sure what you mean here.
>> > >>
>> > >> For clock related properties in the device tree:
>> > >>
>> > >> &tcon_top {
>> > >>
>> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> > >>
>> > >> <&ccu CLK_TCON_TV0>,
>> > >> <&tve0>,
>> > >> <&ccu CLK_TCON_TV1>,
>> > >> <&tve1>;
>> > >>
>> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> > >>
>> > >> };
>> > >>
>> > >> &tcon_tv0 {
>> > >>
>> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> > >> clock-names = "ahb", "tcon-ch1";
>> > >>
>> > >> };
>> > >>
>> > >> A diagram would look like:
>> > >> | This part is TCON TOP |
>> > >>
>> > >> v v
>> > >>
>> > >> CCU CLK_TCON_TV0 --|----\ |
>> > >>
>> > >> | mux ---- gate ----|-- TCON_TV0
>> > >>
>> > >> TVE0 --------------|----/ |
>> > >>
>> > >> And the same goes for TCON_TV1 and TVE1.
>> > >>
>> > >> The user manual is a bit lacking on how TVE outputs a clock though.
>> > >
>> > > I didn't yet received any response on HW details from AW till now, but I
>> > > would like to post new version of patches soon.
>> > >
>> > > While chaining like you described could be implemented easily, I don't
>> > > think it really represents HW as it is. Tests showed that these two
>> > > clocks are independent, otherwise register writes/reads wouldn't be
>> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
>> > > parent becase if it is not enabled, it simply won't work.
>> >
>> > AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
>> > is disabled, register accesses still work.
>>
>> You're right, I just tested that.
>>
>> > I'm saying that the TCON TOP
>> > gate is downstream from the TCON channel clock in the CCU. These are not
>> > related to the TCON bus clock in the CCU, which affects register access.
>> >
>> > Did Allwinner provide any information regarding the hierarchy of the
>> > clocks?
>> No reponse for now.
>>
>> > > However, if everyone feels chaining is the best way to implement it,
>> > > I'll
>> > > do it.
>> >
>> > I would like to get it right and match actual hardware. My proposal is
>> > based on my understanding from the diagrams in the user manual.
>>
>> So for now, your explanation is the most reasonable. Should we go ahead and
>> implement your idea?
>>
>> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one
>> TV TCON instead of two of each kind. That means we will have hole in
>> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
>> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
>> exactly the same.
>
> I just noticed issue with this proposal. If we have following clock chain for
> HDMI, everythings is ok:
>
> TCON-TV0 -> TCON-TOP-TV0
>
> TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock and
> everything works.
>
> However, when TVE will be configured, it would look like this:
>
> TVE0 -> TCON-TOP-TV0
>
> TVE driver will set TVE0 clock to 216 MHz and TCON TV would set TCON-TOP-TV0
> rate which in turn sets TVE0 clock to something like 13.5 MHz (or whatever is
> the right clock rate for PAL and NTSC). As you can see, same clock is set to
> two different rates by two different drivers.
>
> It *might* still work, since encoders set clock rate after TCON (at least that
> is my experience for HDMI pipeline), but that is still wrong.
>
> To overcome above issue, I would stick to original proposal with additional
> clock specified in TCON TV DT node. That way TCON driver would always set
> clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere with
> setting clock rate, because TCON-TV0 clock would be decoupled in TCON-TOP mux.
>
> What do you think?
I think this is the wrong representation, and worse, you are trying to work
around software issues with it.
So to confirm some details, the TVE expects 216 MHz clock, and it expects the
TCON to run and output data at 216 MHz as well. Is that correct?
Would any settings for the TCON differ between when HDMI or TVE is used?
Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt it.
It might be expecting 297 MHz for PC resolutions.
I think these kinds of quirks should be handled in the software, instead of
being papered over.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 3:51 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-25 3:51 UTC (permalink / raw)
To: Jernej Škrabec
Cc: linux-sunxi, Maxime Ripard, Rob Herring, David Airlie,
Gustavo Padovan, Maarten Lankhorst, Sean Paul, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk
On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
<jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
>> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
>> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec <jernej.skrabec@siol.net>
>>
>> wrote:
>> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
>> > >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> > >
>> > > wrote:
>> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> napisal(a):
>> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> > >> >>
>> > >> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>>
>> napisal(a):
>> > >> >> >> Hi,
>> > >> >> >>
>> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional gate
>> > >> >> >> > in
>> > >> >> >> > order
>> > >> >> >> > to work.
>> > >> >> >> >
>> > >> >> >> > Add support for such TCONs.
>> > >> >> >> >
>> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> > >> >> >> > ---
>> > >> >> >> >
>> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> > >> >> >> > 2 files changed, 15 insertions(+)
>> > >> >> >> >
>> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> > >> >> >> > 08747fc3ee71..0afb5a94a414
>> > >> >> >> > 100644
>> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> > >> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct
>> > >> >> >> > device
>> > >> >> >> > *dev,
>> > >> >> >> >
>> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> > >> >> >> > return PTR_ERR(tcon->clk);
>> > >> >> >> >
>> > >> >> >> > }
>> > >> >> >> >
>> > >> >> >> > +
>> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> > >> >> >> > clock\n");
>> > >> >> >> > + return PTR_ERR(tcon->top_clk);
>> > >> >> >> > + }
>> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
>> > >> >> >> > + }
>> > >> >> >> > +
>> > >> >> >>
>> > >> >> >> Is it required for the TCON itself to operate, or does the TCON
>> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
>> > >> >> >> functional?
>> > >> >> >>
>> > >> >> >> I find it quite odd to have a clock that isn't meant for a
>> > >> >> >> particular
>> > >> >> >> device to actually be wired to another device. I'm not saying
>> > >> >> >> this
>> > >> >> >> isn't the case, but it would be a first.
>> > >> >> >
>> > >> >> > Documentation doesn't say much about that gate. I did few tests
>> > >> >> > and
>> > >> >> > TCON
>> > >> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> > >> >> > disabled. However, there is no image, as expected.
>> > >> >>
>> > >> >> The R40 manual does include it in the diagram, on page 504. There's
>> > >> >> also
>> > >> >> a
>> > >> >> mux to select whether the clock comes directly from the CCU or the
>> > >> >> TV
>> > >> >> encoder (a feedback mode?). I assume this is the gate you are
>> > >> >> referring
>> > >> >> to
>> > >> >> here, in which case it is not a bus clock, but rather the TCON
>> > >> >> module
>> > >> >> or
>> > >> >> channel clock, strangely routed.
>> > >> >>
>> > >> >> > More interestingly, I enabled test pattern directly in TCON to
>> > >> >> > eliminate
>> > >> >> > influence of the mixer. As soon as I disabled that gate, test
>> > >> >> > pattern
>> > >> >> > on
>> > >> >> > HDMI screen was gone, which suggest that this gate influences
>> > >> >> > something
>> > >> >> > inside TCON.
>> > >> >> >
>> > >> >> > Another test I did was that I moved enable/disable gate code to
>> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> > >> >> >
>> > >> >> > I'll ask AW engineer what that gate actually does, but from what I
>> > >> >> > saw,
>> > >> >> > I
>> > >> >> > would say that most appropriate location to enable/disable TCON
>> > >> >> > TOP
>> > >> >> > TV
>> > >> >> > TCON
>> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if
>> > >> >> > any
>> > >> >> > TV
>> > >> >> > TCON is in use and enable appropriate gate. However, that doesn't
>> > >> >> > sound
>> > >> >> > right to me for some reason.
>> > >> >>
>> > >> >> If what I said above it true, then yes, the appropriate location to
>> > >> >> enable
>> > >> >> it is the TCON driver, but moreover, the representation of the clock
>> > >> >> tree
>> > >> >> should be fixed such that the TCON takes the clock from the TCON TOP
>> > >> >> as
>> > >> >> its
>> > >> >> channel/ module clock instead. That way you don't need this patch,
>> > >> >> but
>> > >> >> you'd add another for all the clock routing.
>> > >> >
>> > >> > Can you be more specific? I not sure what you mean here.
>> > >>
>> > >> For clock related properties in the device tree:
>> > >>
>> > >> &tcon_top {
>> > >>
>> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> > >>
>> > >> <&ccu CLK_TCON_TV0>,
>> > >> <&tve0>,
>> > >> <&ccu CLK_TCON_TV1>,
>> > >> <&tve1>;
>> > >>
>> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> > >>
>> > >> };
>> > >>
>> > >> &tcon_tv0 {
>> > >>
>> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> > >> clock-names = "ahb", "tcon-ch1";
>> > >>
>> > >> };
>> > >>
>> > >> A diagram would look like:
>> > >> | This part is TCON TOP |
>> > >>
>> > >> v v
>> > >>
>> > >> CCU CLK_TCON_TV0 --|----\ |
>> > >>
>> > >> | mux ---- gate ----|-- TCON_TV0
>> > >>
>> > >> TVE0 --------------|----/ |
>> > >>
>> > >> And the same goes for TCON_TV1 and TVE1.
>> > >>
>> > >> The user manual is a bit lacking on how TVE outputs a clock though.
>> > >
>> > > I didn't yet received any response on HW details from AW till now, but I
>> > > would like to post new version of patches soon.
>> > >
>> > > While chaining like you described could be implemented easily, I don't
>> > > think it really represents HW as it is. Tests showed that these two
>> > > clocks are independent, otherwise register writes/reads wouldn't be
>> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as a
>> > > parent becase if it is not enabled, it simply won't work.
>> >
>> > AFAIK with the TCONs, even when the TCON channel clock (not the bus clock)
>> > is disabled, register accesses still work.
>>
>> You're right, I just tested that.
>>
>> > I'm saying that the TCON TOP
>> > gate is downstream from the TCON channel clock in the CCU. These are not
>> > related to the TCON bus clock in the CCU, which affects register access.
>> >
>> > Did Allwinner provide any information regarding the hierarchy of the
>> > clocks?
>> No reponse for now.
>>
>> > > However, if everyone feels chaining is the best way to implement it,
>> > > I'll
>> > > do it.
>> >
>> > I would like to get it right and match actual hardware. My proposal is
>> > based on my understanding from the diagrams in the user manual.
>>
>> So for now, your explanation is the most reasonable. Should we go ahead and
>> implement your idea?
>>
>> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and one
>> TV TCON instead of two of each kind. That means we will have hole in
>> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
>> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
>> exactly the same.
>
> I just noticed issue with this proposal. If we have following clock chain for
> HDMI, everythings is ok:
>
> TCON-TV0 -> TCON-TOP-TV0
>
> TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock and
> everything works.
>
> However, when TVE will be configured, it would look like this:
>
> TVE0 -> TCON-TOP-TV0
>
> TVE driver will set TVE0 clock to 216 MHz and TCON TV would set TCON-TOP-TV0
> rate which in turn sets TVE0 clock to something like 13.5 MHz (or whatever is
> the right clock rate for PAL and NTSC). As you can see, same clock is set to
> two different rates by two different drivers.
>
> It *might* still work, since encoders set clock rate after TCON (at least that
> is my experience for HDMI pipeline), but that is still wrong.
>
> To overcome above issue, I would stick to original proposal with additional
> clock specified in TCON TV DT node. That way TCON driver would always set
> clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere with
> setting clock rate, because TCON-TV0 clock would be decoupled in TCON-TOP mux.
>
> What do you think?
I think this is the wrong representation, and worse, you are trying to work
around software issues with it.
So to confirm some details, the TVE expects 216 MHz clock, and it expects the
TCON to run and output data at 216 MHz as well. Is that correct?
Would any settings for the TCON differ between when HDMI or TVE is used?
Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt it.
It might be expecting 297 MHz for PC resolutions.
I think these kinds of quirks should be handled in the software, instead of
being papered over.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 7:58 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 7:58 UTC (permalink / raw)
To: linux-sunxi, wens
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
>
> <jernej.skrabec@gmail.com> wrote:
> > Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
> >> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
> >> > <jernej.skrabec@siol.net>
> >>
> >> wrote:
> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
napisal(a):
> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> >> > >> <jernej.skrabec@siol.net>
> >> > >
> >> > > wrote:
> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >
> > napisal(a):
> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >> > >> >>
> >> > >> >> <jernej.skrabec@siol.net> wrote:
> >> > >> >> > Hi,
> >> > >> >> >
> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
> >>
> >> napisal(a):
> >> > >> >> >> Hi,
> >> > >> >> >>
> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
wrote:
> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
> >> > >> >> >> > gate
> >> > >> >> >> > in
> >> > >> >> >> > order
> >> > >> >> >> > to work.
> >> > >> >> >> >
> >> > >> >> >> > Add support for such TCONs.
> >> > >> >> >> >
> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > >> >> >> > ---
> >> > >> >> >> >
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> > >> >> >> >
> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> > >> >> >> > 100644
> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> > >> >> >> > device
> >> > >> >> >> > *dev,
> >> > >> >> >> >
> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> > >> >> >> >
> >> > >> >> >> > }
> >> > >> >> >> >
> >> > >> >> >> > +
> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP
> >> > >> >> >> > bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > +
> >> > >> >> >>
> >> > >> >> >> Is it required for the TCON itself to operate, or does the
> >> > >> >> >> TCON
> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> > >> >> >> functional?
> >> > >> >> >>
> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> > >> >> >> particular
> >> > >> >> >> device to actually be wired to another device. I'm not saying
> >> > >> >> >> this
> >> > >> >> >> isn't the case, but it would be a first.
> >> > >> >> >
> >> > >> >> > Documentation doesn't say much about that gate. I did few tests
> >> > >> >> > and
> >> > >> >> > TCON
> >> > >> >> > registers can be read and written even if TCON TOP TV TCON gate
> >> > >> >> > is
> >> > >> >> > disabled. However, there is no image, as expected.
> >> > >> >>
> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> > >> >> There's
> >> > >> >> also
> >> > >> >> a
> >> > >> >> mux to select whether the clock comes directly from the CCU or
> >> > >> >> the
> >> > >> >> TV
> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> > >> >> referring
> >> > >> >> to
> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
> >> > >> >> module
> >> > >> >> or
> >> > >> >> channel clock, strangely routed.
> >> > >> >>
> >> > >> >> > More interestingly, I enabled test pattern directly in TCON to
> >> > >> >> > eliminate
> >> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> > >> >> > pattern
> >> > >> >> > on
> >> > >> >> > HDMI screen was gone, which suggest that this gate influences
> >> > >> >> > something
> >> > >> >> > inside TCON.
> >> > >> >> >
> >> > >> >> > Another test I did was that I moved enable/disable gate code to
> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> > >> >> >
> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
> >> > >> >> > what I
> >> > >> >> > saw,
> >> > >> >> > I
> >> > >> >> > would say that most appropriate location to enable/disable TCON
> >> > >> >> > TOP
> >> > >> >> > TV
> >> > >> >> > TCON
> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check
> >> > >> >> > if
> >> > >> >> > any
> >> > >> >> > TV
> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> > >> >> > doesn't
> >> > >> >> > sound
> >> > >> >> > right to me for some reason.
> >> > >> >>
> >> > >> >> If what I said above it true, then yes, the appropriate location
> >> > >> >> to
> >> > >> >> enable
> >> > >> >> it is the TCON driver, but moreover, the representation of the
> >> > >> >> clock
> >> > >> >> tree
> >> > >> >> should be fixed such that the TCON takes the clock from the TCON
> >> > >> >> TOP
> >> > >> >> as
> >> > >> >> its
> >> > >> >> channel/ module clock instead. That way you don't need this
> >> > >> >> patch,
> >> > >> >> but
> >> > >> >> you'd add another for all the clock routing.
> >> > >> >
> >> > >> > Can you be more specific? I not sure what you mean here.
> >> > >>
> >> > >> For clock related properties in the device tree:
> >> > >>
> >> > >> &tcon_top {
> >> > >>
> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >> > >>
> >> > >> <&ccu CLK_TCON_TV0>,
> >> > >> <&tve0>,
> >> > >> <&ccu CLK_TCON_TV1>,
> >> > >> <&tve1>;
> >> > >>
> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >> > >>
> >> > >> };
> >> > >>
> >> > >> &tcon_tv0 {
> >> > >>
> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> > >> clock-names = "ahb", "tcon-ch1";
> >> > >>
> >> > >> };
> >> > >>
> >> > >> A diagram would look like:
> >> > >> | This part is TCON TOP |
> >> > >>
> >> > >> v v
> >> > >>
> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> > >>
> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> > >>
> >> > >> TVE0 --------------|----/ |
> >> > >>
> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> > >>
> >> > >> The user manual is a bit lacking on how TVE outputs a clock though.
> >> > >
> >> > > I didn't yet received any response on HW details from AW till now,
> >> > > but I
> >> > > would like to post new version of patches soon.
> >> > >
> >> > > While chaining like you described could be implemented easily, I
> >> > > don't
> >> > > think it really represents HW as it is. Tests showed that these two
> >> > > clocks are independent, otherwise register writes/reads wouldn't be
> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as
> >> > > a
> >> > > parent becase if it is not enabled, it simply won't work.
> >> >
> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
> >> > clock)
> >> > is disabled, register accesses still work.
> >>
> >> You're right, I just tested that.
> >>
> >> > I'm saying that the TCON TOP
> >> > gate is downstream from the TCON channel clock in the CCU. These are
> >> > not
> >> > related to the TCON bus clock in the CCU, which affects register
> >> > access.
> >> >
> >> > Did Allwinner provide any information regarding the hierarchy of the
> >> > clocks?
> >>
> >> No reponse for now.
> >>
> >> > > However, if everyone feels chaining is the best way to implement it,
> >> > > I'll
> >> > > do it.
> >> >
> >> > I would like to get it right and match actual hardware. My proposal is
> >> > based on my understanding from the diagrams in the user manual.
> >>
> >> So for now, your explanation is the most reasonable. Should we go ahead
> >> and
> >> implement your idea?
> >>
> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
> >> one
> >> TV TCON instead of two of each kind. That means we will have hole in
> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> >> exactly the same.
> >
> > I just noticed issue with this proposal. If we have following clock chain
> > for HDMI, everythings is ok:
> >
> > TCON-TV0 -> TCON-TOP-TV0
> >
> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
> > and
> > everything works.
> >
> > However, when TVE will be configured, it would look like this:
> >
> > TVE0 -> TCON-TOP-TV0
> >
> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
> > see, same clock is set to two different rates by two different drivers.
> >
> > It *might* still work, since encoders set clock rate after TCON (at least
> > that is my experience for HDMI pipeline), but that is still wrong.
> >
> > To overcome above issue, I would stick to original proposal with
> > additional
> > clock specified in TCON TV DT node. That way TCON driver would always set
> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere
> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> > TCON-TOP mux.
> >
> > What do you think?
>
> I think this is the wrong representation, and worse, you are trying to work
> around software issues with it.
>
> So to confirm some details, the TVE expects 216 MHz clock, and it expects
> the TCON to run and output data at 216 MHz as well. Is that correct?
Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC, e.g.
TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
>
> Would any settings for the TCON differ between when HDMI or TVE is used?
>
Apart of clock, no, other settings would be the same.
> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt
> it. It might be expecting 297 MHz for PC resolutions.
Please check this table in BSP:
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
video/sunxi/disp2/tv/drv_tv.c#L24
216 MHz is applicable for low resolution, interlaced modes. Modes like 1080P,
1080I have expected standard timing.
>
> I think these kinds of quirks should be handled in the software, instead of
> being papered over.
Ok, that works for me too. I would just like to have such design that would
later allow implementing TVE driver without much issues.
BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel clock
at all, since it is controlled with TVE clock (same case as it would be here,
if TCON TOP mux is switched to TVE clock source).
Maybe quirk can be added that it doesn't set clock rate at all if it is
connected to TVE?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 7:58 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:52 AM, Jernej ?krabec
>
> <jernej.skrabec@gmail.com> wrote:
> > Dne ?etrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej ?krabec napisal(a):
> >> Dne ?etrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej ?krabec
> >> > <jernej.skrabec@siol.net>
> >>
> >> wrote:
> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
napisal(a):
> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec
> >> > >> <jernej.skrabec@siol.net>
> >> > >
> >> > > wrote:
> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >
> > napisal(a):
> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
> >> > >> >>
> >> > >> >> <jernej.skrabec@siol.net> wrote:
> >> > >> >> > Hi,
> >> > >> >> >
> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
> >>
> >> napisal(a):
> >> > >> >> >> Hi,
> >> > >> >> >>
> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
wrote:
> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
> >> > >> >> >> > gate
> >> > >> >> >> > in
> >> > >> >> >> > order
> >> > >> >> >> > to work.
> >> > >> >> >> >
> >> > >> >> >> > Add support for such TCONs.
> >> > >> >> >> >
> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > >> >> >> > ---
> >> > >> >> >> >
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> > >> >> >> >
> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> > >> >> >> > 100644
> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> > >> >> >> > device
> >> > >> >> >> > *dev,
> >> > >> >> >> >
> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> > >> >> >> >
> >> > >> >> >> > }
> >> > >> >> >> >
> >> > >> >> >> > +
> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP
> >> > >> >> >> > bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > +
> >> > >> >> >>
> >> > >> >> >> Is it required for the TCON itself to operate, or does the
> >> > >> >> >> TCON
> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> > >> >> >> functional?
> >> > >> >> >>
> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> > >> >> >> particular
> >> > >> >> >> device to actually be wired to another device. I'm not saying
> >> > >> >> >> this
> >> > >> >> >> isn't the case, but it would be a first.
> >> > >> >> >
> >> > >> >> > Documentation doesn't say much about that gate. I did few tests
> >> > >> >> > and
> >> > >> >> > TCON
> >> > >> >> > registers can be read and written even if TCON TOP TV TCON gate
> >> > >> >> > is
> >> > >> >> > disabled. However, there is no image, as expected.
> >> > >> >>
> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> > >> >> There's
> >> > >> >> also
> >> > >> >> a
> >> > >> >> mux to select whether the clock comes directly from the CCU or
> >> > >> >> the
> >> > >> >> TV
> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> > >> >> referring
> >> > >> >> to
> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
> >> > >> >> module
> >> > >> >> or
> >> > >> >> channel clock, strangely routed.
> >> > >> >>
> >> > >> >> > More interestingly, I enabled test pattern directly in TCON to
> >> > >> >> > eliminate
> >> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> > >> >> > pattern
> >> > >> >> > on
> >> > >> >> > HDMI screen was gone, which suggest that this gate influences
> >> > >> >> > something
> >> > >> >> > inside TCON.
> >> > >> >> >
> >> > >> >> > Another test I did was that I moved enable/disable gate code to
> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> > >> >> >
> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
> >> > >> >> > what I
> >> > >> >> > saw,
> >> > >> >> > I
> >> > >> >> > would say that most appropriate location to enable/disable TCON
> >> > >> >> > TOP
> >> > >> >> > TV
> >> > >> >> > TCON
> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check
> >> > >> >> > if
> >> > >> >> > any
> >> > >> >> > TV
> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> > >> >> > doesn't
> >> > >> >> > sound
> >> > >> >> > right to me for some reason.
> >> > >> >>
> >> > >> >> If what I said above it true, then yes, the appropriate location
> >> > >> >> to
> >> > >> >> enable
> >> > >> >> it is the TCON driver, but moreover, the representation of the
> >> > >> >> clock
> >> > >> >> tree
> >> > >> >> should be fixed such that the TCON takes the clock from the TCON
> >> > >> >> TOP
> >> > >> >> as
> >> > >> >> its
> >> > >> >> channel/ module clock instead. That way you don't need this
> >> > >> >> patch,
> >> > >> >> but
> >> > >> >> you'd add another for all the clock routing.
> >> > >> >
> >> > >> > Can you be more specific? I not sure what you mean here.
> >> > >>
> >> > >> For clock related properties in the device tree:
> >> > >>
> >> > >> &tcon_top {
> >> > >>
> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >> > >>
> >> > >> <&ccu CLK_TCON_TV0>,
> >> > >> <&tve0>,
> >> > >> <&ccu CLK_TCON_TV1>,
> >> > >> <&tve1>;
> >> > >>
> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >> > >>
> >> > >> };
> >> > >>
> >> > >> &tcon_tv0 {
> >> > >>
> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> > >> clock-names = "ahb", "tcon-ch1";
> >> > >>
> >> > >> };
> >> > >>
> >> > >> A diagram would look like:
> >> > >> | This part is TCON TOP |
> >> > >>
> >> > >> v v
> >> > >>
> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> > >>
> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> > >>
> >> > >> TVE0 --------------|----/ |
> >> > >>
> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> > >>
> >> > >> The user manual is a bit lacking on how TVE outputs a clock though.
> >> > >
> >> > > I didn't yet received any response on HW details from AW till now,
> >> > > but I
> >> > > would like to post new version of patches soon.
> >> > >
> >> > > While chaining like you described could be implemented easily, I
> >> > > don't
> >> > > think it really represents HW as it is. Tests showed that these two
> >> > > clocks are independent, otherwise register writes/reads wouldn't be
> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as
> >> > > a
> >> > > parent becase if it is not enabled, it simply won't work.
> >> >
> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
> >> > clock)
> >> > is disabled, register accesses still work.
> >>
> >> You're right, I just tested that.
> >>
> >> > I'm saying that the TCON TOP
> >> > gate is downstream from the TCON channel clock in the CCU. These are
> >> > not
> >> > related to the TCON bus clock in the CCU, which affects register
> >> > access.
> >> >
> >> > Did Allwinner provide any information regarding the hierarchy of the
> >> > clocks?
> >>
> >> No reponse for now.
> >>
> >> > > However, if everyone feels chaining is the best way to implement it,
> >> > > I'll
> >> > > do it.
> >> >
> >> > I would like to get it right and match actual hardware. My proposal is
> >> > based on my understanding from the diagrams in the user manual.
> >>
> >> So for now, your explanation is the most reasonable. Should we go ahead
> >> and
> >> implement your idea?
> >>
> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
> >> one
> >> TV TCON instead of two of each kind. That means we will have hole in
> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> >> exactly the same.
> >
> > I just noticed issue with this proposal. If we have following clock chain
> > for HDMI, everythings is ok:
> >
> > TCON-TV0 -> TCON-TOP-TV0
> >
> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
> > and
> > everything works.
> >
> > However, when TVE will be configured, it would look like this:
> >
> > TVE0 -> TCON-TOP-TV0
> >
> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
> > see, same clock is set to two different rates by two different drivers.
> >
> > It *might* still work, since encoders set clock rate after TCON (at least
> > that is my experience for HDMI pipeline), but that is still wrong.
> >
> > To overcome above issue, I would stick to original proposal with
> > additional
> > clock specified in TCON TV DT node. That way TCON driver would always set
> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere
> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> > TCON-TOP mux.
> >
> > What do you think?
>
> I think this is the wrong representation, and worse, you are trying to work
> around software issues with it.
>
> So to confirm some details, the TVE expects 216 MHz clock, and it expects
> the TCON to run and output data at 216 MHz as well. Is that correct?
Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC, e.g.
TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
>
> Would any settings for the TCON differ between when HDMI or TVE is used?
>
Apart of clock, no, other settings would be the same.
> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt
> it. It might be expecting 297 MHz for PC resolutions.
Please check this table in BSP:
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
video/sunxi/disp2/tv/drv_tv.c#L24
216 MHz is applicable for low resolution, interlaced modes. Modes like 1080P,
1080I have expected standard timing.
>
> I think these kinds of quirks should be handled in the software, instead of
> being papered over.
Ok, that works for me too. I would just like to have such design that would
later allow implementing TVE driver without much issues.
BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel clock
at all, since it is controlled with TVE clock (same case as it would be here,
if TCON TOP mux is switched to TVE clock source).
Maybe quirk can be added that it doesn't set clock rate at all if it is
connected to TVE?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 7:58 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 7:58 UTC (permalink / raw)
To: linux-sunxi, wens
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:52 AM, Jernej =C5=A0krabec
>=20
> <jernej.skrabec@gmail.com> wrote:
> > Dne =C4=8Detrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej =C5=A0krabe=
c napisal(a):
> >> Dne =C4=8Detrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napi=
sal(a):
> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej =C5=A0krabec
> >> > <jernej.skrabec@siol.net>
> >>=20
> >> wrote:
> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai=20
napisal(a):
> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej =C5=A0krabec
> >> > >> <jernej.skrabec@siol.net>
> >> > >=20
> >> > > wrote:
> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >=20
> > napisal(a):
> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej =C5=A0krabec
> >> > >> >>=20
> >> > >> >> <jernej.skrabec@siol.net> wrote:
> >> > >> >> > Hi,
> >> > >> >> >=20
> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
> >>=20
> >> napisal(a):
> >> > >> >> >> Hi,
> >> > >> >> >>=20
> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec=20
wrote:
> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
> >> > >> >> >> > gate
> >> > >> >> >> > in
> >> > >> >> >> > order
> >> > >> >> >> > to work.
> >> > >> >> >> >=20
> >> > >> >> >> > Add support for such TCONs.
> >> > >> >> >> >=20
> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> > >> >> >> > ---
> >> > >> >> >> >=20
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> > >> >> >> >=20
> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> > >> >> >> > 100644
> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> > >> >> >> > device
> >> > >> >> >> > *dev,
> >> > >> >> >> >=20
> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> > >> >> >> > =20
> >> > >> >> >> > }
> >> > >> >> >> >=20
> >> > >> >> >> > +
> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > >> >> >> > + tcon->top_clk =3D devm_clk_get(dev, "tcon-top=
");
> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON T=
OP
> >> > >> >> >> > bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > +
> >> > >> >> >>=20
> >> > >> >> >> Is it required for the TCON itself to operate, or does the
> >> > >> >> >> TCON
> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to=
be
> >> > >> >> >> functional?
> >> > >> >> >>=20
> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> > >> >> >> particular
> >> > >> >> >> device to actually be wired to another device. I'm not sayi=
ng
> >> > >> >> >> this
> >> > >> >> >> isn't the case, but it would be a first.
> >> > >> >> >=20
> >> > >> >> > Documentation doesn't say much about that gate. I did few te=
sts
> >> > >> >> > and
> >> > >> >> > TCON
> >> > >> >> > registers can be read and written even if TCON TOP TV TCON g=
ate
> >> > >> >> > is
> >> > >> >> > disabled. However, there is no image, as expected.
> >> > >> >>=20
> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> > >> >> There's
> >> > >> >> also
> >> > >> >> a
> >> > >> >> mux to select whether the clock comes directly from the CCU or
> >> > >> >> the
> >> > >> >> TV
> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> > >> >> referring
> >> > >> >> to
> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
> >> > >> >> module
> >> > >> >> or
> >> > >> >> channel clock, strangely routed.
> >> > >> >>=20
> >> > >> >> > More interestingly, I enabled test pattern directly in TCON =
to
> >> > >> >> > eliminate
> >> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> > >> >> > pattern
> >> > >> >> > on
> >> > >> >> > HDMI screen was gone, which suggest that this gate influences
> >> > >> >> > something
> >> > >> >> > inside TCON.
> >> > >> >> >=20
> >> > >> >> > Another test I did was that I moved enable/disable gate code=
to
> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> > >> >> >=20
> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
> >> > >> >> > what I
> >> > >> >> > saw,
> >> > >> >> > I
> >> > >> >> > would say that most appropriate location to enable/disable T=
CON
> >> > >> >> > TOP
> >> > >> >> > TV
> >> > >> >> > TCON
> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could ch=
eck
> >> > >> >> > if
> >> > >> >> > any
> >> > >> >> > TV
> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> > >> >> > doesn't
> >> > >> >> > sound
> >> > >> >> > right to me for some reason.
> >> > >> >>=20
> >> > >> >> If what I said above it true, then yes, the appropriate locati=
on
> >> > >> >> to
> >> > >> >> enable
> >> > >> >> it is the TCON driver, but moreover, the representation of the
> >> > >> >> clock
> >> > >> >> tree
> >> > >> >> should be fixed such that the TCON takes the clock from the TC=
ON
> >> > >> >> TOP
> >> > >> >> as
> >> > >> >> its
> >> > >> >> channel/ module clock instead. That way you don't need this
> >> > >> >> patch,
> >> > >> >> but
> >> > >> >> you'd add another for all the clock routing.
> >> > >> >=20
> >> > >> > Can you be more specific? I not sure what you mean here.
> >> > >>=20
> >> > >> For clock related properties in the device tree:
> >> > >>=20
> >> > >> &tcon_top {
> >> > >>=20
> >> > >> clocks =3D <&ccu CLK_BUS_TCON_TOP>,
> >> > >> =20
> >> > >> <&ccu CLK_TCON_TV0>,
> >> > >> <&tve0>,
> >> > >> <&ccu CLK_TCON_TV1>,
> >> > >> <&tve1>;
> >> > >> =20
> >> > >> clock-names =3D "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> > >> clock-output-names =3D "tcon-top-tv0", "tcon-top-tv1";
> >> > >>=20
> >> > >> };
> >> > >>=20
> >> > >> &tcon_tv0 {
> >> > >>=20
> >> > >> clocks =3D <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> > >> clock-names =3D "ahb", "tcon-ch1";
> >> > >>=20
> >> > >> };
> >> > >>=20
> >> > >> A diagram would look like:
> >> > >> | This part is TCON TOP |
> >> > >> =20
> >> > >> v v
> >> > >>=20
> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> > >>=20
> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> > >>=20
> >> > >> TVE0 --------------|----/ |
> >> > >>=20
> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> > >>=20
> >> > >> The user manual is a bit lacking on how TVE outputs a clock thoug=
h.
> >> > >=20
> >> > > I didn't yet received any response on HW details from AW till now,
> >> > > but I
> >> > > would like to post new version of patches soon.
> >> > >=20
> >> > > While chaining like you described could be implemented easily, I
> >> > > don't
> >> > > think it really represents HW as it is. Tests showed that these two
> >> > > clocks are independent, otherwise register writes/reads wouldn't be
> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock =
as
> >> > > a
> >> > > parent becase if it is not enabled, it simply won't work.
> >> >=20
> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
> >> > clock)
> >> > is disabled, register accesses still work.
> >>=20
> >> You're right, I just tested that.
> >>=20
> >> > I'm saying that the TCON TOP
> >> > gate is downstream from the TCON channel clock in the CCU. These are
> >> > not
> >> > related to the TCON bus clock in the CCU, which affects register
> >> > access.
> >> >=20
> >> > Did Allwinner provide any information regarding the hierarchy of the
> >> > clocks?
> >>=20
> >> No reponse for now.
> >>=20
> >> > > However, if everyone feels chaining is the best way to implement i=
t,
> >> > > I'll
> >> > > do it.
> >> >=20
> >> > I would like to get it right and match actual hardware. My proposal =
is
> >> > based on my understanding from the diagrams in the user manual.
> >>=20
> >> So for now, your explanation is the most reasonable. Should we go ahead
> >> and
> >> implement your idea?
> >>=20
> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
> >> one
> >> TV TCON instead of two of each kind. That means we will have hole in
> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> >> exactly the same.
> >=20
> > I just noticed issue with this proposal. If we have following clock cha=
in
> > for HDMI, everythings is ok:
> >=20
> > TCON-TV0 -> TCON-TOP-TV0
> >=20
> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
> > and
> > everything works.
> >=20
> > However, when TVE will be configured, it would look like this:
> >=20
> > TVE0 -> TCON-TOP-TV0
> >=20
> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
> > see, same clock is set to two different rates by two different drivers.
> >=20
> > It *might* still work, since encoders set clock rate after TCON (at lea=
st
> > that is my experience for HDMI pipeline), but that is still wrong.
> >=20
> > To overcome above issue, I would stick to original proposal with
> > additional
> > clock specified in TCON TV DT node. That way TCON driver would always s=
et
> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfe=
re
> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> > TCON-TOP mux.
> >=20
> > What do you think?
>=20
> I think this is the wrong representation, and worse, you are trying to wo=
rk
> around software issues with it.
>=20
> So to confirm some details, the TVE expects 216 MHz clock, and it expects
> the TCON to run and output data at 216 MHz as well. Is that correct?
Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC, e=
=2Eg.=20
TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
>=20
> Would any settings for the TCON differ between when HDMI or TVE is used?
>=20
Apart of clock, no, other settings would be the same.
> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt
> it. It might be expecting 297 MHz for PC resolutions.
Please check this table in BSP:
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
video/sunxi/disp2/tv/drv_tv.c#L24
216 MHz is applicable for low resolution, interlaced modes. Modes like 1080=
P,=20
1080I have expected standard timing.
>=20
> I think these kinds of quirks should be handled in the software, instead =
of
> being papered over.
Ok, that works for me too. I would just like to have such design that would=
=20
later allow implementing TVE driver without much issues.
BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel cloc=
k=20
at all, since it is controlled with TVE clock (same case as it would be her=
e,=20
if TCON TOP mux is switched to TVE clock source).
Maybe quirk can be added that it doesn't set clock rate at all if it is=20
connected to TVE?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 7:58 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 7:58 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, wens-jdAy2FN1RRM
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
>
> <jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
> >> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
> >> > <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >>
> >> wrote:
> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
napisal(a):
> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> >> > >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> > >
> >> > > wrote:
> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >
> > napisal(a):
> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >> > >> >>
> >> > >> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> >> > >> >> > Hi,
> >> > >> >> >
> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
> >>
> >> napisal(a):
> >> > >> >> >> Hi,
> >> > >> >> >>
> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
wrote:
> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
> >> > >> >> >> > gate
> >> > >> >> >> > in
> >> > >> >> >> > order
> >> > >> >> >> > to work.
> >> > >> >> >> >
> >> > >> >> >> > Add support for such TCONs.
> >> > >> >> >> >
> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> > >> >> >> > ---
> >> > >> >> >> >
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> > >> >> >> >
> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> > >> >> >> > 100644
> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> > >> >> >> > device
> >> > >> >> >> > *dev,
> >> > >> >> >> >
> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> > >> >> >> >
> >> > >> >> >> > }
> >> > >> >> >> >
> >> > >> >> >> > +
> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP
> >> > >> >> >> > bus
> >> > >> >> >> > clock\n");
> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> > >> >> >> > + }
> >> > >> >> >> > +
> >> > >> >> >>
> >> > >> >> >> Is it required for the TCON itself to operate, or does the
> >> > >> >> >> TCON
> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
> >> > >> >> >> functional?
> >> > >> >> >>
> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> > >> >> >> particular
> >> > >> >> >> device to actually be wired to another device. I'm not saying
> >> > >> >> >> this
> >> > >> >> >> isn't the case, but it would be a first.
> >> > >> >> >
> >> > >> >> > Documentation doesn't say much about that gate. I did few tests
> >> > >> >> > and
> >> > >> >> > TCON
> >> > >> >> > registers can be read and written even if TCON TOP TV TCON gate
> >> > >> >> > is
> >> > >> >> > disabled. However, there is no image, as expected.
> >> > >> >>
> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> > >> >> There's
> >> > >> >> also
> >> > >> >> a
> >> > >> >> mux to select whether the clock comes directly from the CCU or
> >> > >> >> the
> >> > >> >> TV
> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> > >> >> referring
> >> > >> >> to
> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
> >> > >> >> module
> >> > >> >> or
> >> > >> >> channel clock, strangely routed.
> >> > >> >>
> >> > >> >> > More interestingly, I enabled test pattern directly in TCON to
> >> > >> >> > eliminate
> >> > >> >> > influence of the mixer. As soon as I disabled that gate, test
> >> > >> >> > pattern
> >> > >> >> > on
> >> > >> >> > HDMI screen was gone, which suggest that this gate influences
> >> > >> >> > something
> >> > >> >> > inside TCON.
> >> > >> >> >
> >> > >> >> > Another test I did was that I moved enable/disable gate code to
> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> > >> >> >
> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
> >> > >> >> > what I
> >> > >> >> > saw,
> >> > >> >> > I
> >> > >> >> > would say that most appropriate location to enable/disable TCON
> >> > >> >> > TOP
> >> > >> >> > TV
> >> > >> >> > TCON
> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check
> >> > >> >> > if
> >> > >> >> > any
> >> > >> >> > TV
> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> > >> >> > doesn't
> >> > >> >> > sound
> >> > >> >> > right to me for some reason.
> >> > >> >>
> >> > >> >> If what I said above it true, then yes, the appropriate location
> >> > >> >> to
> >> > >> >> enable
> >> > >> >> it is the TCON driver, but moreover, the representation of the
> >> > >> >> clock
> >> > >> >> tree
> >> > >> >> should be fixed such that the TCON takes the clock from the TCON
> >> > >> >> TOP
> >> > >> >> as
> >> > >> >> its
> >> > >> >> channel/ module clock instead. That way you don't need this
> >> > >> >> patch,
> >> > >> >> but
> >> > >> >> you'd add another for all the clock routing.
> >> > >> >
> >> > >> > Can you be more specific? I not sure what you mean here.
> >> > >>
> >> > >> For clock related properties in the device tree:
> >> > >>
> >> > >> &tcon_top {
> >> > >>
> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >> > >>
> >> > >> <&ccu CLK_TCON_TV0>,
> >> > >> <&tve0>,
> >> > >> <&ccu CLK_TCON_TV1>,
> >> > >> <&tve1>;
> >> > >>
> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >> > >>
> >> > >> };
> >> > >>
> >> > >> &tcon_tv0 {
> >> > >>
> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> > >> clock-names = "ahb", "tcon-ch1";
> >> > >>
> >> > >> };
> >> > >>
> >> > >> A diagram would look like:
> >> > >> | This part is TCON TOP |
> >> > >>
> >> > >> v v
> >> > >>
> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> > >>
> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> > >>
> >> > >> TVE0 --------------|----/ |
> >> > >>
> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> > >>
> >> > >> The user manual is a bit lacking on how TVE outputs a clock though.
> >> > >
> >> > > I didn't yet received any response on HW details from AW till now,
> >> > > but I
> >> > > would like to post new version of patches soon.
> >> > >
> >> > > While chaining like you described could be implemented easily, I
> >> > > don't
> >> > > think it really represents HW as it is. Tests showed that these two
> >> > > clocks are independent, otherwise register writes/reads wouldn't be
> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as
> >> > > a
> >> > > parent becase if it is not enabled, it simply won't work.
> >> >
> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
> >> > clock)
> >> > is disabled, register accesses still work.
> >>
> >> You're right, I just tested that.
> >>
> >> > I'm saying that the TCON TOP
> >> > gate is downstream from the TCON channel clock in the CCU. These are
> >> > not
> >> > related to the TCON bus clock in the CCU, which affects register
> >> > access.
> >> >
> >> > Did Allwinner provide any information regarding the hierarchy of the
> >> > clocks?
> >>
> >> No reponse for now.
> >>
> >> > > However, if everyone feels chaining is the best way to implement it,
> >> > > I'll
> >> > > do it.
> >> >
> >> > I would like to get it right and match actual hardware. My proposal is
> >> > based on my understanding from the diagrams in the user manual.
> >>
> >> So for now, your explanation is the most reasonable. Should we go ahead
> >> and
> >> implement your idea?
> >>
> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
> >> one
> >> TV TCON instead of two of each kind. That means we will have hole in
> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> >> exactly the same.
> >
> > I just noticed issue with this proposal. If we have following clock chain
> > for HDMI, everythings is ok:
> >
> > TCON-TV0 -> TCON-TOP-TV0
> >
> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
> > and
> > everything works.
> >
> > However, when TVE will be configured, it would look like this:
> >
> > TVE0 -> TCON-TOP-TV0
> >
> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
> > see, same clock is set to two different rates by two different drivers.
> >
> > It *might* still work, since encoders set clock rate after TCON (at least
> > that is my experience for HDMI pipeline), but that is still wrong.
> >
> > To overcome above issue, I would stick to original proposal with
> > additional
> > clock specified in TCON TV DT node. That way TCON driver would always set
> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere
> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> > TCON-TOP mux.
> >
> > What do you think?
>
> I think this is the wrong representation, and worse, you are trying to work
> around software issues with it.
>
> So to confirm some details, the TVE expects 216 MHz clock, and it expects
> the TCON to run and output data at 216 MHz as well. Is that correct?
Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC, e.g.
TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
>
> Would any settings for the TCON differ between when HDMI or TVE is used?
>
Apart of clock, no, other settings would be the same.
> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt
> it. It might be expecting 297 MHz for PC resolutions.
Please check this table in BSP:
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
video/sunxi/disp2/tv/drv_tv.c#L24
216 MHz is applicable for low resolution, interlaced modes. Modes like 1080P,
1080I have expected standard timing.
>
> I think these kinds of quirks should be handled in the software, instead of
> being papered over.
Ok, that works for me too. I would just like to have such design that would
later allow implementing TVE driver without much issues.
BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel clock
at all, since it is controlled with TVE clock (same case as it would be here,
if TCON TOP mux is switched to TVE clock source).
Maybe quirk can be added that it doesn't set clock rate at all if it is
connected to TVE?
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
2018-06-25 7:58 ` Jernej Škrabec
(?)
@ 2018-06-25 8:14 ` Chen-Yu Tsai
-1 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-25 8:14 UTC (permalink / raw)
To: Jernej Škrabec
Cc: linux-sunxi, Maxime Ripard, Rob Herring, David Airlie,
Gustavo Padovan, Maarten Lankhorst, Sean Paul, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk
On Mon, Jun 25, 2018 at 3:58 PM, Jernej Škrabec
<jernej.skrabec@gmail.com> wrote:
> Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai napisal(a):
>> On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
>>
>> <jernej.skrabec@gmail.com> wrote:
>> > Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
>> >> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
>> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
>> >> > <jernej.skrabec@siol.net>
>> >>
>> >> wrote:
>> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
> napisal(a):
>> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
>> >> > >> <jernej.skrabec@siol.net>
>> >> > >
>> >> > > wrote:
>> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
>> >
>> > napisal(a):
>> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> >> > >> >>
>> >> > >> >> <jernej.skrabec@siol.net> wrote:
>> >> > >> >> > Hi,
>> >> > >> >> >
>> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>> >>
>> >> napisal(a):
>> >> > >> >> >> Hi,
>> >> > >> >> >>
>> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
> wrote:
>> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
>> >> > >> >> >> > gate
>> >> > >> >> >> > in
>> >> > >> >> >> > order
>> >> > >> >> >> > to work.
>> >> > >> >> >> >
>> >> > >> >> >> > Add support for such TCONs.
>> >> > >> >> >> >
>> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> >> > >> >> >> > ---
>> >> > >> >> >> >
>> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> > >> >> >> > 2 files changed, 15 insertions(+)
>> >> > >> >> >> >
>> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
>> >> > >> >> >> > 100644
>> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
>> >> > >> >> >> > sun4i_tcon_init_clocks(struct
>> >> > >> >> >> > device
>> >> > >> >> >> > *dev,
>> >> > >> >> >> >
>> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
>> >> > >> >> >> > clock\n");
>> >> > >> >> >> > return PTR_ERR(tcon->clk);
>> >> > >> >> >> >
>> >> > >> >> >> > }
>> >> > >> >> >> >
>> >> > >> >> >> > +
>> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP
>> >> > >> >> >> > bus
>> >> > >> >> >> > clock\n");
>> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
>> >> > >> >> >> > + }
>> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
>> >> > >> >> >> > + }
>> >> > >> >> >> > +
>> >> > >> >> >>
>> >> > >> >> >> Is it required for the TCON itself to operate, or does the
>> >> > >> >> >> TCON
>> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
>> >> > >> >> >> functional?
>> >> > >> >> >>
>> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
>> >> > >> >> >> particular
>> >> > >> >> >> device to actually be wired to another device. I'm not saying
>> >> > >> >> >> this
>> >> > >> >> >> isn't the case, but it would be a first.
>> >> > >> >> >
>> >> > >> >> > Documentation doesn't say much about that gate. I did few tests
>> >> > >> >> > and
>> >> > >> >> > TCON
>> >> > >> >> > registers can be read and written even if TCON TOP TV TCON gate
>> >> > >> >> > is
>> >> > >> >> > disabled. However, there is no image, as expected.
>> >> > >> >>
>> >> > >> >> The R40 manual does include it in the diagram, on page 504.
>> >> > >> >> There's
>> >> > >> >> also
>> >> > >> >> a
>> >> > >> >> mux to select whether the clock comes directly from the CCU or
>> >> > >> >> the
>> >> > >> >> TV
>> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
>> >> > >> >> referring
>> >> > >> >> to
>> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
>> >> > >> >> module
>> >> > >> >> or
>> >> > >> >> channel clock, strangely routed.
>> >> > >> >>
>> >> > >> >> > More interestingly, I enabled test pattern directly in TCON to
>> >> > >> >> > eliminate
>> >> > >> >> > influence of the mixer. As soon as I disabled that gate, test
>> >> > >> >> > pattern
>> >> > >> >> > on
>> >> > >> >> > HDMI screen was gone, which suggest that this gate influences
>> >> > >> >> > something
>> >> > >> >> > inside TCON.
>> >> > >> >> >
>> >> > >> >> > Another test I did was that I moved enable/disable gate code to
>> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >> > >> >> >
>> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
>> >> > >> >> > what I
>> >> > >> >> > saw,
>> >> > >> >> > I
>> >> > >> >> > would say that most appropriate location to enable/disable TCON
>> >> > >> >> > TOP
>> >> > >> >> > TV
>> >> > >> >> > TCON
>> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check
>> >> > >> >> > if
>> >> > >> >> > any
>> >> > >> >> > TV
>> >> > >> >> > TCON is in use and enable appropriate gate. However, that
>> >> > >> >> > doesn't
>> >> > >> >> > sound
>> >> > >> >> > right to me for some reason.
>> >> > >> >>
>> >> > >> >> If what I said above it true, then yes, the appropriate location
>> >> > >> >> to
>> >> > >> >> enable
>> >> > >> >> it is the TCON driver, but moreover, the representation of the
>> >> > >> >> clock
>> >> > >> >> tree
>> >> > >> >> should be fixed such that the TCON takes the clock from the TCON
>> >> > >> >> TOP
>> >> > >> >> as
>> >> > >> >> its
>> >> > >> >> channel/ module clock instead. That way you don't need this
>> >> > >> >> patch,
>> >> > >> >> but
>> >> > >> >> you'd add another for all the clock routing.
>> >> > >> >
>> >> > >> > Can you be more specific? I not sure what you mean here.
>> >> > >>
>> >> > >> For clock related properties in the device tree:
>> >> > >>
>> >> > >> &tcon_top {
>> >> > >>
>> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> >> > >>
>> >> > >> <&ccu CLK_TCON_TV0>,
>> >> > >> <&tve0>,
>> >> > >> <&ccu CLK_TCON_TV1>,
>> >> > >> <&tve1>;
>> >> > >>
>> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> >> > >>
>> >> > >> };
>> >> > >>
>> >> > >> &tcon_tv0 {
>> >> > >>
>> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> >> > >> clock-names = "ahb", "tcon-ch1";
>> >> > >>
>> >> > >> };
>> >> > >>
>> >> > >> A diagram would look like:
>> >> > >> | This part is TCON TOP |
>> >> > >>
>> >> > >> v v
>> >> > >>
>> >> > >> CCU CLK_TCON_TV0 --|----\ |
>> >> > >>
>> >> > >> | mux ---- gate ----|-- TCON_TV0
>> >> > >>
>> >> > >> TVE0 --------------|----/ |
>> >> > >>
>> >> > >> And the same goes for TCON_TV1 and TVE1.
>> >> > >>
>> >> > >> The user manual is a bit lacking on how TVE outputs a clock though.
>> >> > >
>> >> > > I didn't yet received any response on HW details from AW till now,
>> >> > > but I
>> >> > > would like to post new version of patches soon.
>> >> > >
>> >> > > While chaining like you described could be implemented easily, I
>> >> > > don't
>> >> > > think it really represents HW as it is. Tests showed that these two
>> >> > > clocks are independent, otherwise register writes/reads wouldn't be
>> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as
>> >> > > a
>> >> > > parent becase if it is not enabled, it simply won't work.
>> >> >
>> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
>> >> > clock)
>> >> > is disabled, register accesses still work.
>> >>
>> >> You're right, I just tested that.
>> >>
>> >> > I'm saying that the TCON TOP
>> >> > gate is downstream from the TCON channel clock in the CCU. These are
>> >> > not
>> >> > related to the TCON bus clock in the CCU, which affects register
>> >> > access.
>> >> >
>> >> > Did Allwinner provide any information regarding the hierarchy of the
>> >> > clocks?
>> >>
>> >> No reponse for now.
>> >>
>> >> > > However, if everyone feels chaining is the best way to implement it,
>> >> > > I'll
>> >> > > do it.
>> >> >
>> >> > I would like to get it right and match actual hardware. My proposal is
>> >> > based on my understanding from the diagrams in the user manual.
>> >>
>> >> So for now, your explanation is the most reasonable. Should we go ahead
>> >> and
>> >> implement your idea?
>> >>
>> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
>> >> one
>> >> TV TCON instead of two of each kind. That means we will have hole in
>> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
>> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
>> >> exactly the same.
>> >
>> > I just noticed issue with this proposal. If we have following clock chain
>> > for HDMI, everythings is ok:
>> >
>> > TCON-TV0 -> TCON-TOP-TV0
>> >
>> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
>> > and
>> > everything works.
>> >
>> > However, when TVE will be configured, it would look like this:
>> >
>> > TVE0 -> TCON-TOP-TV0
>> >
>> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
>> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
>> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
>> > see, same clock is set to two different rates by two different drivers.
>> >
>> > It *might* still work, since encoders set clock rate after TCON (at least
>> > that is my experience for HDMI pipeline), but that is still wrong.
>> >
>> > To overcome above issue, I would stick to original proposal with
>> > additional
>> > clock specified in TCON TV DT node. That way TCON driver would always set
>> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere
>> > with setting clock rate, because TCON-TV0 clock would be decoupled in
>> > TCON-TOP mux.
>> >
>> > What do you think?
>>
>> I think this is the wrong representation, and worse, you are trying to work
>> around software issues with it.
>>
>> So to confirm some details, the TVE expects 216 MHz clock, and it expects
>> the TCON to run and output data at 216 MHz as well. Is that correct?
>
> Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC, e.g.
> TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
>
>>
>> Would any settings for the TCON differ between when HDMI or TVE is used?
>>
>
> Apart of clock, no, other settings would be the same.
>
>> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt
>> it. It might be expecting 297 MHz for PC resolutions.
>
> Please check this table in BSP:
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
> video/sunxi/disp2/tv/drv_tv.c#L24
>
> 216 MHz is applicable for low resolution, interlaced modes. Modes like 1080P,
> 1080I have expected standard timing.
That's weird. So it only applies to SDTV video resolutions. I remember
seeing an "up sampling" setting for composite in the TVE, which goes all
the way up to 216 MHz. Maybe that's the reason?
I wonder how the TCON manages this though. I mean with the dot clock this
high, doesn't that mean the frame rate is much higher?
>>
>> I think these kinds of quirks should be handled in the software, instead of
>> being papered over.
>
> Ok, that works for me too. I would just like to have such design that would
> later allow implementing TVE driver without much issues.
>
> BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel clock
> at all, since it is controlled with TVE clock (same case as it would be here,
> if TCON TOP mux is switched to TVE clock source).
Does it require 216 MHz as well?
> Maybe quirk can be added that it doesn't set clock rate at all if it is
> connected to TVE?
A quirk yes. But the dot clock would be 216 MHz instead of not setting it,
and only for certain display modes. To be honest I think we can get by with
just a TODO note for now.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 8:14 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-25 8:14 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jun 25, 2018 at 3:58 PM, Jernej ?krabec
<jernej.skrabec@gmail.com> wrote:
> Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai napisal(a):
>> On Mon, Jun 25, 2018 at 3:52 AM, Jernej ?krabec
>>
>> <jernej.skrabec@gmail.com> wrote:
>> > Dne ?etrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej ?krabec napisal(a):
>> >> Dne ?etrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
>> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej ?krabec
>> >> > <jernej.skrabec@siol.net>
>> >>
>> >> wrote:
>> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
> napisal(a):
>> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec
>> >> > >> <jernej.skrabec@siol.net>
>> >> > >
>> >> > > wrote:
>> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
>> >
>> > napisal(a):
>> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
>> >> > >> >>
>> >> > >> >> <jernej.skrabec@siol.net> wrote:
>> >> > >> >> > Hi,
>> >> > >> >> >
>> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>> >>
>> >> napisal(a):
>> >> > >> >> >> Hi,
>> >> > >> >> >>
>> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
> wrote:
>> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
>> >> > >> >> >> > gate
>> >> > >> >> >> > in
>> >> > >> >> >> > order
>> >> > >> >> >> > to work.
>> >> > >> >> >> >
>> >> > >> >> >> > Add support for such TCONs.
>> >> > >> >> >> >
>> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> >> > >> >> >> > ---
>> >> > >> >> >> >
>> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> > >> >> >> > 2 files changed, 15 insertions(+)
>> >> > >> >> >> >
>> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
>> >> > >> >> >> > 100644
>> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
>> >> > >> >> >> > sun4i_tcon_init_clocks(struct
>> >> > >> >> >> > device
>> >> > >> >> >> > *dev,
>> >> > >> >> >> >
>> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
>> >> > >> >> >> > clock\n");
>> >> > >> >> >> > return PTR_ERR(tcon->clk);
>> >> > >> >> >> >
>> >> > >> >> >> > }
>> >> > >> >> >> >
>> >> > >> >> >> > +
>> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP
>> >> > >> >> >> > bus
>> >> > >> >> >> > clock\n");
>> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
>> >> > >> >> >> > + }
>> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
>> >> > >> >> >> > + }
>> >> > >> >> >> > +
>> >> > >> >> >>
>> >> > >> >> >> Is it required for the TCON itself to operate, or does the
>> >> > >> >> >> TCON
>> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
>> >> > >> >> >> functional?
>> >> > >> >> >>
>> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
>> >> > >> >> >> particular
>> >> > >> >> >> device to actually be wired to another device. I'm not saying
>> >> > >> >> >> this
>> >> > >> >> >> isn't the case, but it would be a first.
>> >> > >> >> >
>> >> > >> >> > Documentation doesn't say much about that gate. I did few tests
>> >> > >> >> > and
>> >> > >> >> > TCON
>> >> > >> >> > registers can be read and written even if TCON TOP TV TCON gate
>> >> > >> >> > is
>> >> > >> >> > disabled. However, there is no image, as expected.
>> >> > >> >>
>> >> > >> >> The R40 manual does include it in the diagram, on page 504.
>> >> > >> >> There's
>> >> > >> >> also
>> >> > >> >> a
>> >> > >> >> mux to select whether the clock comes directly from the CCU or
>> >> > >> >> the
>> >> > >> >> TV
>> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
>> >> > >> >> referring
>> >> > >> >> to
>> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
>> >> > >> >> module
>> >> > >> >> or
>> >> > >> >> channel clock, strangely routed.
>> >> > >> >>
>> >> > >> >> > More interestingly, I enabled test pattern directly in TCON to
>> >> > >> >> > eliminate
>> >> > >> >> > influence of the mixer. As soon as I disabled that gate, test
>> >> > >> >> > pattern
>> >> > >> >> > on
>> >> > >> >> > HDMI screen was gone, which suggest that this gate influences
>> >> > >> >> > something
>> >> > >> >> > inside TCON.
>> >> > >> >> >
>> >> > >> >> > Another test I did was that I moved enable/disable gate code to
>> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >> > >> >> >
>> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
>> >> > >> >> > what I
>> >> > >> >> > saw,
>> >> > >> >> > I
>> >> > >> >> > would say that most appropriate location to enable/disable TCON
>> >> > >> >> > TOP
>> >> > >> >> > TV
>> >> > >> >> > TCON
>> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check
>> >> > >> >> > if
>> >> > >> >> > any
>> >> > >> >> > TV
>> >> > >> >> > TCON is in use and enable appropriate gate. However, that
>> >> > >> >> > doesn't
>> >> > >> >> > sound
>> >> > >> >> > right to me for some reason.
>> >> > >> >>
>> >> > >> >> If what I said above it true, then yes, the appropriate location
>> >> > >> >> to
>> >> > >> >> enable
>> >> > >> >> it is the TCON driver, but moreover, the representation of the
>> >> > >> >> clock
>> >> > >> >> tree
>> >> > >> >> should be fixed such that the TCON takes the clock from the TCON
>> >> > >> >> TOP
>> >> > >> >> as
>> >> > >> >> its
>> >> > >> >> channel/ module clock instead. That way you don't need this
>> >> > >> >> patch,
>> >> > >> >> but
>> >> > >> >> you'd add another for all the clock routing.
>> >> > >> >
>> >> > >> > Can you be more specific? I not sure what you mean here.
>> >> > >>
>> >> > >> For clock related properties in the device tree:
>> >> > >>
>> >> > >> &tcon_top {
>> >> > >>
>> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> >> > >>
>> >> > >> <&ccu CLK_TCON_TV0>,
>> >> > >> <&tve0>,
>> >> > >> <&ccu CLK_TCON_TV1>,
>> >> > >> <&tve1>;
>> >> > >>
>> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> >> > >>
>> >> > >> };
>> >> > >>
>> >> > >> &tcon_tv0 {
>> >> > >>
>> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> >> > >> clock-names = "ahb", "tcon-ch1";
>> >> > >>
>> >> > >> };
>> >> > >>
>> >> > >> A diagram would look like:
>> >> > >> | This part is TCON TOP |
>> >> > >>
>> >> > >> v v
>> >> > >>
>> >> > >> CCU CLK_TCON_TV0 --|----\ |
>> >> > >>
>> >> > >> | mux ---- gate ----|-- TCON_TV0
>> >> > >>
>> >> > >> TVE0 --------------|----/ |
>> >> > >>
>> >> > >> And the same goes for TCON_TV1 and TVE1.
>> >> > >>
>> >> > >> The user manual is a bit lacking on how TVE outputs a clock though.
>> >> > >
>> >> > > I didn't yet received any response on HW details from AW till now,
>> >> > > but I
>> >> > > would like to post new version of patches soon.
>> >> > >
>> >> > > While chaining like you described could be implemented easily, I
>> >> > > don't
>> >> > > think it really represents HW as it is. Tests showed that these two
>> >> > > clocks are independent, otherwise register writes/reads wouldn't be
>> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as
>> >> > > a
>> >> > > parent becase if it is not enabled, it simply won't work.
>> >> >
>> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
>> >> > clock)
>> >> > is disabled, register accesses still work.
>> >>
>> >> You're right, I just tested that.
>> >>
>> >> > I'm saying that the TCON TOP
>> >> > gate is downstream from the TCON channel clock in the CCU. These are
>> >> > not
>> >> > related to the TCON bus clock in the CCU, which affects register
>> >> > access.
>> >> >
>> >> > Did Allwinner provide any information regarding the hierarchy of the
>> >> > clocks?
>> >>
>> >> No reponse for now.
>> >>
>> >> > > However, if everyone feels chaining is the best way to implement it,
>> >> > > I'll
>> >> > > do it.
>> >> >
>> >> > I would like to get it right and match actual hardware. My proposal is
>> >> > based on my understanding from the diagrams in the user manual.
>> >>
>> >> So for now, your explanation is the most reasonable. Should we go ahead
>> >> and
>> >> implement your idea?
>> >>
>> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
>> >> one
>> >> TV TCON instead of two of each kind. That means we will have hole in
>> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
>> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
>> >> exactly the same.
>> >
>> > I just noticed issue with this proposal. If we have following clock chain
>> > for HDMI, everythings is ok:
>> >
>> > TCON-TV0 -> TCON-TOP-TV0
>> >
>> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
>> > and
>> > everything works.
>> >
>> > However, when TVE will be configured, it would look like this:
>> >
>> > TVE0 -> TCON-TOP-TV0
>> >
>> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
>> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
>> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
>> > see, same clock is set to two different rates by two different drivers.
>> >
>> > It *might* still work, since encoders set clock rate after TCON (at least
>> > that is my experience for HDMI pipeline), but that is still wrong.
>> >
>> > To overcome above issue, I would stick to original proposal with
>> > additional
>> > clock specified in TCON TV DT node. That way TCON driver would always set
>> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere
>> > with setting clock rate, because TCON-TV0 clock would be decoupled in
>> > TCON-TOP mux.
>> >
>> > What do you think?
>>
>> I think this is the wrong representation, and worse, you are trying to work
>> around software issues with it.
>>
>> So to confirm some details, the TVE expects 216 MHz clock, and it expects
>> the TCON to run and output data at 216 MHz as well. Is that correct?
>
> Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC, e.g.
> TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
>
>>
>> Would any settings for the TCON differ between when HDMI or TVE is used?
>>
>
> Apart of clock, no, other settings would be the same.
>
>> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt
>> it. It might be expecting 297 MHz for PC resolutions.
>
> Please check this table in BSP:
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
> video/sunxi/disp2/tv/drv_tv.c#L24
>
> 216 MHz is applicable for low resolution, interlaced modes. Modes like 1080P,
> 1080I have expected standard timing.
That's weird. So it only applies to SDTV video resolutions. I remember
seeing an "up sampling" setting for composite in the TVE, which goes all
the way up to 216 MHz. Maybe that's the reason?
I wonder how the TCON manages this though. I mean with the dot clock this
high, doesn't that mean the frame rate is much higher?
>>
>> I think these kinds of quirks should be handled in the software, instead of
>> being papered over.
>
> Ok, that works for me too. I would just like to have such design that would
> later allow implementing TVE driver without much issues.
>
> BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel clock
> at all, since it is controlled with TVE clock (same case as it would be here,
> if TCON TOP mux is switched to TVE clock source).
Does it require 216 MHz as well?
> Maybe quirk can be added that it doesn't set clock rate at all if it is
> connected to TVE?
A quirk yes. But the dot clock would be 216 MHz instead of not setting it,
and only for certain display modes. To be honest I think we can get by with
just a TODO note for now.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 8:14 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-25 8:14 UTC (permalink / raw)
To: Jernej Škrabec
Cc: linux-sunxi, Maxime Ripard, Rob Herring, David Airlie,
Gustavo Padovan, Maarten Lankhorst, Sean Paul, Mark Rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk
On Mon, Jun 25, 2018 at 3:58 PM, Jernej Škrabec
<jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai napisal(a):
>> On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
>>
>> <jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec napisal(a):
>> >> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai napisal(a):
>> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
>> >> > <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> >>
>> >> wrote:
>> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
> napisal(a):
>> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
>> >> > >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> >> > >
>> >> > > wrote:
>> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
>> >
>> > napisal(a):
>> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> >> > >> >>
>> >> > >> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
>> >> > >> >> > Hi,
>> >> > >> >> >
>> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
>> >>
>> >> napisal(a):
>> >> > >> >> >> Hi,
>> >> > >> >> >>
>> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
> wrote:
>> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
>> >> > >> >> >> > gate
>> >> > >> >> >> > in
>> >> > >> >> >> > order
>> >> > >> >> >> > to work.
>> >> > >> >> >> >
>> >> > >> >> >> > Add support for such TCONs.
>> >> > >> >> >> >
>> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> >> > >> >> >> > ---
>> >> > >> >> >> >
>> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
>> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
>> >> > >> >> >> > 2 files changed, 15 insertions(+)
>> >> > >> >> >> >
>> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
>> >> > >> >> >> > 100644
>> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
>> >> > >> >> >> > sun4i_tcon_init_clocks(struct
>> >> > >> >> >> > device
>> >> > >> >> >> > *dev,
>> >> > >> >> >> >
>> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
>> >> > >> >> >> > clock\n");
>> >> > >> >> >> > return PTR_ERR(tcon->clk);
>> >> > >> >> >> >
>> >> > >> >> >> > }
>> >> > >> >> >> >
>> >> > >> >> >> > +
>> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON TOP
>> >> > >> >> >> > bus
>> >> > >> >> >> > clock\n");
>> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
>> >> > >> >> >> > + }
>> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
>> >> > >> >> >> > + }
>> >> > >> >> >> > +
>> >> > >> >> >>
>> >> > >> >> >> Is it required for the TCON itself to operate, or does the
>> >> > >> >> >> TCON
>> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to be
>> >> > >> >> >> functional?
>> >> > >> >> >>
>> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
>> >> > >> >> >> particular
>> >> > >> >> >> device to actually be wired to another device. I'm not saying
>> >> > >> >> >> this
>> >> > >> >> >> isn't the case, but it would be a first.
>> >> > >> >> >
>> >> > >> >> > Documentation doesn't say much about that gate. I did few tests
>> >> > >> >> > and
>> >> > >> >> > TCON
>> >> > >> >> > registers can be read and written even if TCON TOP TV TCON gate
>> >> > >> >> > is
>> >> > >> >> > disabled. However, there is no image, as expected.
>> >> > >> >>
>> >> > >> >> The R40 manual does include it in the diagram, on page 504.
>> >> > >> >> There's
>> >> > >> >> also
>> >> > >> >> a
>> >> > >> >> mux to select whether the clock comes directly from the CCU or
>> >> > >> >> the
>> >> > >> >> TV
>> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
>> >> > >> >> referring
>> >> > >> >> to
>> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
>> >> > >> >> module
>> >> > >> >> or
>> >> > >> >> channel clock, strangely routed.
>> >> > >> >>
>> >> > >> >> > More interestingly, I enabled test pattern directly in TCON to
>> >> > >> >> > eliminate
>> >> > >> >> > influence of the mixer. As soon as I disabled that gate, test
>> >> > >> >> > pattern
>> >> > >> >> > on
>> >> > >> >> > HDMI screen was gone, which suggest that this gate influences
>> >> > >> >> > something
>> >> > >> >> > inside TCON.
>> >> > >> >> >
>> >> > >> >> > Another test I did was that I moved enable/disable gate code to
>> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >> > >> >> >
>> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
>> >> > >> >> > what I
>> >> > >> >> > saw,
>> >> > >> >> > I
>> >> > >> >> > would say that most appropriate location to enable/disable TCON
>> >> > >> >> > TOP
>> >> > >> >> > TV
>> >> > >> >> > TCON
>> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could check
>> >> > >> >> > if
>> >> > >> >> > any
>> >> > >> >> > TV
>> >> > >> >> > TCON is in use and enable appropriate gate. However, that
>> >> > >> >> > doesn't
>> >> > >> >> > sound
>> >> > >> >> > right to me for some reason.
>> >> > >> >>
>> >> > >> >> If what I said above it true, then yes, the appropriate location
>> >> > >> >> to
>> >> > >> >> enable
>> >> > >> >> it is the TCON driver, but moreover, the representation of the
>> >> > >> >> clock
>> >> > >> >> tree
>> >> > >> >> should be fixed such that the TCON takes the clock from the TCON
>> >> > >> >> TOP
>> >> > >> >> as
>> >> > >> >> its
>> >> > >> >> channel/ module clock instead. That way you don't need this
>> >> > >> >> patch,
>> >> > >> >> but
>> >> > >> >> you'd add another for all the clock routing.
>> >> > >> >
>> >> > >> > Can you be more specific? I not sure what you mean here.
>> >> > >>
>> >> > >> For clock related properties in the device tree:
>> >> > >>
>> >> > >> &tcon_top {
>> >> > >>
>> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
>> >> > >>
>> >> > >> <&ccu CLK_TCON_TV0>,
>> >> > >> <&tve0>,
>> >> > >> <&ccu CLK_TCON_TV1>,
>> >> > >> <&tve1>;
>> >> > >>
>> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> >> > >>
>> >> > >> };
>> >> > >>
>> >> > >> &tcon_tv0 {
>> >> > >>
>> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
>> >> > >> clock-names = "ahb", "tcon-ch1";
>> >> > >>
>> >> > >> };
>> >> > >>
>> >> > >> A diagram would look like:
>> >> > >> | This part is TCON TOP |
>> >> > >>
>> >> > >> v v
>> >> > >>
>> >> > >> CCU CLK_TCON_TV0 --|----\ |
>> >> > >>
>> >> > >> | mux ---- gate ----|-- TCON_TV0
>> >> > >>
>> >> > >> TVE0 --------------|----/ |
>> >> > >>
>> >> > >> And the same goes for TCON_TV1 and TVE1.
>> >> > >>
>> >> > >> The user manual is a bit lacking on how TVE outputs a clock though.
>> >> > >
>> >> > > I didn't yet received any response on HW details from AW till now,
>> >> > > but I
>> >> > > would like to post new version of patches soon.
>> >> > >
>> >> > > While chaining like you described could be implemented easily, I
>> >> > > don't
>> >> > > think it really represents HW as it is. Tests showed that these two
>> >> > > clocks are independent, otherwise register writes/reads wouldn't be
>> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock as
>> >> > > a
>> >> > > parent becase if it is not enabled, it simply won't work.
>> >> >
>> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
>> >> > clock)
>> >> > is disabled, register accesses still work.
>> >>
>> >> You're right, I just tested that.
>> >>
>> >> > I'm saying that the TCON TOP
>> >> > gate is downstream from the TCON channel clock in the CCU. These are
>> >> > not
>> >> > related to the TCON bus clock in the CCU, which affects register
>> >> > access.
>> >> >
>> >> > Did Allwinner provide any information regarding the hierarchy of the
>> >> > clocks?
>> >>
>> >> No reponse for now.
>> >>
>> >> > > However, if everyone feels chaining is the best way to implement it,
>> >> > > I'll
>> >> > > do it.
>> >> >
>> >> > I would like to get it right and match actual hardware. My proposal is
>> >> > based on my understanding from the diagrams in the user manual.
>> >>
>> >> So for now, your explanation is the most reasonable. Should we go ahead
>> >> and
>> >> implement your idea?
>> >>
>> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
>> >> one
>> >> TV TCON instead of two of each kind. That means we will have hole in
>> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
>> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
>> >> exactly the same.
>> >
>> > I just noticed issue with this proposal. If we have following clock chain
>> > for HDMI, everythings is ok:
>> >
>> > TCON-TV0 -> TCON-TOP-TV0
>> >
>> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
>> > and
>> > everything works.
>> >
>> > However, when TVE will be configured, it would look like this:
>> >
>> > TVE0 -> TCON-TOP-TV0
>> >
>> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
>> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
>> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
>> > see, same clock is set to two different rates by two different drivers.
>> >
>> > It *might* still work, since encoders set clock rate after TCON (at least
>> > that is my experience for HDMI pipeline), but that is still wrong.
>> >
>> > To overcome above issue, I would stick to original proposal with
>> > additional
>> > clock specified in TCON TV DT node. That way TCON driver would always set
>> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't interfere
>> > with setting clock rate, because TCON-TV0 clock would be decoupled in
>> > TCON-TOP mux.
>> >
>> > What do you think?
>>
>> I think this is the wrong representation, and worse, you are trying to work
>> around software issues with it.
>>
>> So to confirm some details, the TVE expects 216 MHz clock, and it expects
>> the TCON to run and output data at 216 MHz as well. Is that correct?
>
> Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC, e.g.
> TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
>
>>
>> Would any settings for the TCON differ between when HDMI or TVE is used?
>>
>
> Apart of clock, no, other settings would be the same.
>
>> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of doubt
>> it. It might be expecting 297 MHz for PC resolutions.
>
> Please check this table in BSP:
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
> video/sunxi/disp2/tv/drv_tv.c#L24
>
> 216 MHz is applicable for low resolution, interlaced modes. Modes like 1080P,
> 1080I have expected standard timing.
That's weird. So it only applies to SDTV video resolutions. I remember
seeing an "up sampling" setting for composite in the TVE, which goes all
the way up to 216 MHz. Maybe that's the reason?
I wonder how the TCON manages this though. I mean with the dot clock this
high, doesn't that mean the frame rate is much higher?
>>
>> I think these kinds of quirks should be handled in the software, instead of
>> being papered over.
>
> Ok, that works for me too. I would just like to have such design that would
> later allow implementing TVE driver without much issues.
>
> BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel clock
> at all, since it is controlled with TVE clock (same case as it would be here,
> if TCON TOP mux is switched to TVE clock source).
Does it require 216 MHz as well?
> Maybe quirk can be added that it doesn't set clock rate at all if it is
> connected to TVE?
A quirk yes. But the dot clock would be 216 MHz instead of not setting it,
and only for certain display modes. To be honest I think we can get by with
just a TODO note for now.
ChenYu
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 9:10 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 9:10 UTC (permalink / raw)
To: linux-sunxi, wens
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne ponedeljek, 25. junij 2018 ob 10:14:52 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:58 PM, Jernej Škrabec
>
> <jernej.skrabec@gmail.com> wrote:
> > Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai
napisal(a):
> >> On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
> >>
> >> <jernej.skrabec@gmail.com> wrote:
> >> > Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec
napisal(a):
> >> >> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai
napisal(a):
> >> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
> >> >> > <jernej.skrabec@siol.net>
> >> >>
> >> >> wrote:
> >> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
> >
> > napisal(a):
> >> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> >> >> > >> <jernej.skrabec@siol.net>
> >> >> > >
> >> >> > > wrote:
> >> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >> >
> >> > napisal(a):
> >> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >> >> > >> >>
> >> >> > >> >> <jernej.skrabec@siol.net> wrote:
> >> >> > >> >> > Hi,
> >> >> > >> >> >
> >> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
> >> >>
> >> >> napisal(a):
> >> >> > >> >> >> Hi,
> >> >> > >> >> >>
> >> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
> >
> > wrote:
> >> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
> >> >> > >> >> >> > gate
> >> >> > >> >> >> > in
> >> >> > >> >> >> > order
> >> >> > >> >> >> > to work.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Add support for such TCONs.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> > >> >> >> > ---
> >> >> > >> >> >> >
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> >> > >> >> >> >
> >> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > >> >> >> > 100644
> >> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> >> > >> >> >> > device
> >> >> > >> >> >> > *dev,
> >> >> > >> >> >> >
> >> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> >> > >> >> >> >
> >> >> > >> >> >> > }
> >> >> > >> >> >> >
> >> >> > >> >> >> > +
> >> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev,
> >> >> > >> >> >> > "tcon-top");
> >> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON
> >> >> > >> >> >> > TOP
> >> >> > >> >> >> > bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > +
> >> >> > >> >> >>
> >> >> > >> >> >> Is it required for the TCON itself to operate, or does the
> >> >> > >> >> >> TCON
> >> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to
> >> >> > >> >> >> be
> >> >> > >> >> >> functional?
> >> >> > >> >> >>
> >> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> >> > >> >> >> particular
> >> >> > >> >> >> device to actually be wired to another device. I'm not
> >> >> > >> >> >> saying
> >> >> > >> >> >> this
> >> >> > >> >> >> isn't the case, but it would be a first.
> >> >> > >> >> >
> >> >> > >> >> > Documentation doesn't say much about that gate. I did few
> >> >> > >> >> > tests
> >> >> > >> >> > and
> >> >> > >> >> > TCON
> >> >> > >> >> > registers can be read and written even if TCON TOP TV TCON
> >> >> > >> >> > gate
> >> >> > >> >> > is
> >> >> > >> >> > disabled. However, there is no image, as expected.
> >> >> > >> >>
> >> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> >> > >> >> There's
> >> >> > >> >> also
> >> >> > >> >> a
> >> >> > >> >> mux to select whether the clock comes directly from the CCU or
> >> >> > >> >> the
> >> >> > >> >> TV
> >> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> >> > >> >> referring
> >> >> > >> >> to
> >> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
> >> >> > >> >> module
> >> >> > >> >> or
> >> >> > >> >> channel clock, strangely routed.
> >> >> > >> >>
> >> >> > >> >> > More interestingly, I enabled test pattern directly in TCON
> >> >> > >> >> > to
> >> >> > >> >> > eliminate
> >> >> > >> >> > influence of the mixer. As soon as I disabled that gate,
> >> >> > >> >> > test
> >> >> > >> >> > pattern
> >> >> > >> >> > on
> >> >> > >> >> > HDMI screen was gone, which suggest that this gate
> >> >> > >> >> > influences
> >> >> > >> >> > something
> >> >> > >> >> > inside TCON.
> >> >> > >> >> >
> >> >> > >> >> > Another test I did was that I moved enable/disable gate code
> >> >> > >> >> > to
> >> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >> > >> >> >
> >> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
> >> >> > >> >> > what I
> >> >> > >> >> > saw,
> >> >> > >> >> > I
> >> >> > >> >> > would say that most appropriate location to enable/disable
> >> >> > >> >> > TCON
> >> >> > >> >> > TOP
> >> >> > >> >> > TV
> >> >> > >> >> > TCON
> >> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could
> >> >> > >> >> > check
> >> >> > >> >> > if
> >> >> > >> >> > any
> >> >> > >> >> > TV
> >> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> >> > >> >> > doesn't
> >> >> > >> >> > sound
> >> >> > >> >> > right to me for some reason.
> >> >> > >> >>
> >> >> > >> >> If what I said above it true, then yes, the appropriate
> >> >> > >> >> location
> >> >> > >> >> to
> >> >> > >> >> enable
> >> >> > >> >> it is the TCON driver, but moreover, the representation of the
> >> >> > >> >> clock
> >> >> > >> >> tree
> >> >> > >> >> should be fixed such that the TCON takes the clock from the
> >> >> > >> >> TCON
> >> >> > >> >> TOP
> >> >> > >> >> as
> >> >> > >> >> its
> >> >> > >> >> channel/ module clock instead. That way you don't need this
> >> >> > >> >> patch,
> >> >> > >> >> but
> >> >> > >> >> you'd add another for all the clock routing.
> >> >> > >> >
> >> >> > >> > Can you be more specific? I not sure what you mean here.
> >> >> > >>
> >> >> > >> For clock related properties in the device tree:
> >> >> > >>
> >> >> > >> &tcon_top {
> >> >> > >>
> >> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >> >> > >>
> >> >> > >> <&ccu CLK_TCON_TV0>,
> >> >> > >> <&tve0>,
> >> >> > >> <&ccu CLK_TCON_TV1>,
> >> >> > >> <&tve1>;
> >> >> > >>
> >> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >> >> > >>
> >> >> > >> };
> >> >> > >>
> >> >> > >> &tcon_tv0 {
> >> >> > >>
> >> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> >> > >> clock-names = "ahb", "tcon-ch1";
> >> >> > >>
> >> >> > >> };
> >> >> > >>
> >> >> > >> A diagram would look like:
> >> >> > >> | This part is TCON TOP |
> >> >> > >>
> >> >> > >> v v
> >> >> > >>
> >> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> >> > >>
> >> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> >> > >>
> >> >> > >> TVE0 --------------|----/ |
> >> >> > >>
> >> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> >> > >>
> >> >> > >> The user manual is a bit lacking on how TVE outputs a clock
> >> >> > >> though.
> >> >> > >
> >> >> > > I didn't yet received any response on HW details from AW till now,
> >> >> > > but I
> >> >> > > would like to post new version of patches soon.
> >> >> > >
> >> >> > > While chaining like you described could be implemented easily, I
> >> >> > > don't
> >> >> > > think it really represents HW as it is. Tests showed that these
> >> >> > > two
> >> >> > > clocks are independent, otherwise register writes/reads wouldn't
> >> >> > > be
> >> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock
> >> >> > > as
> >> >> > > a
> >> >> > > parent becase if it is not enabled, it simply won't work.
> >> >> >
> >> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
> >> >> > clock)
> >> >> > is disabled, register accesses still work.
> >> >>
> >> >> You're right, I just tested that.
> >> >>
> >> >> > I'm saying that the TCON TOP
> >> >> > gate is downstream from the TCON channel clock in the CCU. These are
> >> >> > not
> >> >> > related to the TCON bus clock in the CCU, which affects register
> >> >> > access.
> >> >> >
> >> >> > Did Allwinner provide any information regarding the hierarchy of the
> >> >> > clocks?
> >> >>
> >> >> No reponse for now.
> >> >>
> >> >> > > However, if everyone feels chaining is the best way to implement
> >> >> > > it,
> >> >> > > I'll
> >> >> > > do it.
> >> >> >
> >> >> > I would like to get it right and match actual hardware. My proposal
> >> >> > is
> >> >> > based on my understanding from the diagrams in the user manual.
> >> >>
> >> >> So for now, your explanation is the most reasonable. Should we go
> >> >> ahead
> >> >> and
> >> >> implement your idea?
> >> >>
> >> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
> >> >> one
> >> >> TV TCON instead of two of each kind. That means we will have hole in
> >> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> >> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> >> >> exactly the same.
> >> >
> >> > I just noticed issue with this proposal. If we have following clock
> >> > chain
> >> > for HDMI, everythings is ok:
> >> >
> >> > TCON-TV0 -> TCON-TOP-TV0
> >> >
> >> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
> >> > and
> >> > everything works.
> >> >
> >> > However, when TVE will be configured, it would look like this:
> >> >
> >> > TVE0 -> TCON-TOP-TV0
> >> >
> >> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> >> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
> >> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
> >> > see, same clock is set to two different rates by two different drivers.
> >> >
> >> > It *might* still work, since encoders set clock rate after TCON (at
> >> > least
> >> > that is my experience for HDMI pipeline), but that is still wrong.
> >> >
> >> > To overcome above issue, I would stick to original proposal with
> >> > additional
> >> > clock specified in TCON TV DT node. That way TCON driver would always
> >> > set
> >> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't
> >> > interfere
> >> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> >> > TCON-TOP mux.
> >> >
> >> > What do you think?
> >>
> >> I think this is the wrong representation, and worse, you are trying to
> >> work
> >> around software issues with it.
> >>
> >> So to confirm some details, the TVE expects 216 MHz clock, and it expects
> >> the TCON to run and output data at 216 MHz as well. Is that correct?
> >
> > Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC,
> > e.g. TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
> >
> >> Would any settings for the TCON differ between when HDMI or TVE is used?
> >
> > Apart of clock, no, other settings would be the same.
> >
> >> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of
> >> doubt
> >> it. It might be expecting 297 MHz for PC resolutions.
> >
> > Please check this table in BSP:
> > https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/driver
> > s/ video/sunxi/disp2/tv/drv_tv.c#L24
> >
> > 216 MHz is applicable for low resolution, interlaced modes. Modes like
> > 1080P, 1080I have expected standard timing.
>
> That's weird. So it only applies to SDTV video resolutions. I remember
> seeing an "up sampling" setting for composite in the TVE, which goes all
> the way up to 216 MHz. Maybe that's the reason?
>
Probably. If upsampling is set to 0, it still needs 27 MHz, which is 2x more
than standard PAL/NTSC clock. After studying AC200 manual (which is similar TV
encoder) and its driver, it seems the reason for that is 8 bit parallel
interface between TCON and TVE and 16 bit data (CCIR656).
However, actual tests would be needed to confirm all that.
> I wonder how the TCON manages this though. I mean with the dot clock this
> high, doesn't that mean the frame rate is much higher?
>
Not sure, but IMO it is downscaled somehow in TVE HW to get proper rates at
the end.
> >> I think these kinds of quirks should be handled in the software, instead
> >> of
> >> being papered over.
> >
> > Ok, that works for me too. I would just like to have such design that
> > would
> > later allow implementing TVE driver without much issues.
> >
> > BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel
> > clock at all, since it is controlled with TVE clock (same case as it
> > would be here, if TCON TOP mux is switched to TVE clock source).
>
> Does it require 216 MHz as well?
Yes. It supports only PAL and NTSC (only one DAC), so BSP driver sets TVE
clock to 216 MHz.
>
> > Maybe quirk can be added that it doesn't set clock rate at all if it is
> > connected to TVE?
>
> A quirk yes. But the dot clock would be 216 MHz instead of not setting it,
> and only for certain display modes. To be honest I think we can get by with
> just a TODO note for now.
Why not leave control of channel rate to TVE, since it knows if oversampling
is enabled or not? But that's debate for another time.
I will send new R40 HDMI patches according your original proposal.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 9:10 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 9:10 UTC (permalink / raw)
To: linux-arm-kernel
Dne ponedeljek, 25. junij 2018 ob 10:14:52 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:58 PM, Jernej ?krabec
>
> <jernej.skrabec@gmail.com> wrote:
> > Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai
napisal(a):
> >> On Mon, Jun 25, 2018 at 3:52 AM, Jernej ?krabec
> >>
> >> <jernej.skrabec@gmail.com> wrote:
> >> > Dne ?etrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej ?krabec
napisal(a):
> >> >> Dne ?etrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai
napisal(a):
> >> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej ?krabec
> >> >> > <jernej.skrabec@siol.net>
> >> >>
> >> >> wrote:
> >> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
> >
> > napisal(a):
> >> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej ?krabec
> >> >> > >> <jernej.skrabec@siol.net>
> >> >> > >
> >> >> > > wrote:
> >> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >> >
> >> > napisal(a):
> >> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej ?krabec
> >> >> > >> >>
> >> >> > >> >> <jernej.skrabec@siol.net> wrote:
> >> >> > >> >> > Hi,
> >> >> > >> >> >
> >> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
> >> >>
> >> >> napisal(a):
> >> >> > >> >> >> Hi,
> >> >> > >> >> >>
> >> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
> >
> > wrote:
> >> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
> >> >> > >> >> >> > gate
> >> >> > >> >> >> > in
> >> >> > >> >> >> > order
> >> >> > >> >> >> > to work.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Add support for such TCONs.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> > >> >> >> > ---
> >> >> > >> >> >> >
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> >> > >> >> >> >
> >> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > >> >> >> > 100644
> >> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> >> > >> >> >> > device
> >> >> > >> >> >> > *dev,
> >> >> > >> >> >> >
> >> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> >> > >> >> >> >
> >> >> > >> >> >> > }
> >> >> > >> >> >> >
> >> >> > >> >> >> > +
> >> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev,
> >> >> > >> >> >> > "tcon-top");
> >> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON
> >> >> > >> >> >> > TOP
> >> >> > >> >> >> > bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > +
> >> >> > >> >> >>
> >> >> > >> >> >> Is it required for the TCON itself to operate, or does the
> >> >> > >> >> >> TCON
> >> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to
> >> >> > >> >> >> be
> >> >> > >> >> >> functional?
> >> >> > >> >> >>
> >> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> >> > >> >> >> particular
> >> >> > >> >> >> device to actually be wired to another device. I'm not
> >> >> > >> >> >> saying
> >> >> > >> >> >> this
> >> >> > >> >> >> isn't the case, but it would be a first.
> >> >> > >> >> >
> >> >> > >> >> > Documentation doesn't say much about that gate. I did few
> >> >> > >> >> > tests
> >> >> > >> >> > and
> >> >> > >> >> > TCON
> >> >> > >> >> > registers can be read and written even if TCON TOP TV TCON
> >> >> > >> >> > gate
> >> >> > >> >> > is
> >> >> > >> >> > disabled. However, there is no image, as expected.
> >> >> > >> >>
> >> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> >> > >> >> There's
> >> >> > >> >> also
> >> >> > >> >> a
> >> >> > >> >> mux to select whether the clock comes directly from the CCU or
> >> >> > >> >> the
> >> >> > >> >> TV
> >> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> >> > >> >> referring
> >> >> > >> >> to
> >> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
> >> >> > >> >> module
> >> >> > >> >> or
> >> >> > >> >> channel clock, strangely routed.
> >> >> > >> >>
> >> >> > >> >> > More interestingly, I enabled test pattern directly in TCON
> >> >> > >> >> > to
> >> >> > >> >> > eliminate
> >> >> > >> >> > influence of the mixer. As soon as I disabled that gate,
> >> >> > >> >> > test
> >> >> > >> >> > pattern
> >> >> > >> >> > on
> >> >> > >> >> > HDMI screen was gone, which suggest that this gate
> >> >> > >> >> > influences
> >> >> > >> >> > something
> >> >> > >> >> > inside TCON.
> >> >> > >> >> >
> >> >> > >> >> > Another test I did was that I moved enable/disable gate code
> >> >> > >> >> > to
> >> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >> > >> >> >
> >> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
> >> >> > >> >> > what I
> >> >> > >> >> > saw,
> >> >> > >> >> > I
> >> >> > >> >> > would say that most appropriate location to enable/disable
> >> >> > >> >> > TCON
> >> >> > >> >> > TOP
> >> >> > >> >> > TV
> >> >> > >> >> > TCON
> >> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could
> >> >> > >> >> > check
> >> >> > >> >> > if
> >> >> > >> >> > any
> >> >> > >> >> > TV
> >> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> >> > >> >> > doesn't
> >> >> > >> >> > sound
> >> >> > >> >> > right to me for some reason.
> >> >> > >> >>
> >> >> > >> >> If what I said above it true, then yes, the appropriate
> >> >> > >> >> location
> >> >> > >> >> to
> >> >> > >> >> enable
> >> >> > >> >> it is the TCON driver, but moreover, the representation of the
> >> >> > >> >> clock
> >> >> > >> >> tree
> >> >> > >> >> should be fixed such that the TCON takes the clock from the
> >> >> > >> >> TCON
> >> >> > >> >> TOP
> >> >> > >> >> as
> >> >> > >> >> its
> >> >> > >> >> channel/ module clock instead. That way you don't need this
> >> >> > >> >> patch,
> >> >> > >> >> but
> >> >> > >> >> you'd add another for all the clock routing.
> >> >> > >> >
> >> >> > >> > Can you be more specific? I not sure what you mean here.
> >> >> > >>
> >> >> > >> For clock related properties in the device tree:
> >> >> > >>
> >> >> > >> &tcon_top {
> >> >> > >>
> >> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >> >> > >>
> >> >> > >> <&ccu CLK_TCON_TV0>,
> >> >> > >> <&tve0>,
> >> >> > >> <&ccu CLK_TCON_TV1>,
> >> >> > >> <&tve1>;
> >> >> > >>
> >> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >> >> > >>
> >> >> > >> };
> >> >> > >>
> >> >> > >> &tcon_tv0 {
> >> >> > >>
> >> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> >> > >> clock-names = "ahb", "tcon-ch1";
> >> >> > >>
> >> >> > >> };
> >> >> > >>
> >> >> > >> A diagram would look like:
> >> >> > >> | This part is TCON TOP |
> >> >> > >>
> >> >> > >> v v
> >> >> > >>
> >> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> >> > >>
> >> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> >> > >>
> >> >> > >> TVE0 --------------|----/ |
> >> >> > >>
> >> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> >> > >>
> >> >> > >> The user manual is a bit lacking on how TVE outputs a clock
> >> >> > >> though.
> >> >> > >
> >> >> > > I didn't yet received any response on HW details from AW till now,
> >> >> > > but I
> >> >> > > would like to post new version of patches soon.
> >> >> > >
> >> >> > > While chaining like you described could be implemented easily, I
> >> >> > > don't
> >> >> > > think it really represents HW as it is. Tests showed that these
> >> >> > > two
> >> >> > > clocks are independent, otherwise register writes/reads wouldn't
> >> >> > > be
> >> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock
> >> >> > > as
> >> >> > > a
> >> >> > > parent becase if it is not enabled, it simply won't work.
> >> >> >
> >> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
> >> >> > clock)
> >> >> > is disabled, register accesses still work.
> >> >>
> >> >> You're right, I just tested that.
> >> >>
> >> >> > I'm saying that the TCON TOP
> >> >> > gate is downstream from the TCON channel clock in the CCU. These are
> >> >> > not
> >> >> > related to the TCON bus clock in the CCU, which affects register
> >> >> > access.
> >> >> >
> >> >> > Did Allwinner provide any information regarding the hierarchy of the
> >> >> > clocks?
> >> >>
> >> >> No reponse for now.
> >> >>
> >> >> > > However, if everyone feels chaining is the best way to implement
> >> >> > > it,
> >> >> > > I'll
> >> >> > > do it.
> >> >> >
> >> >> > I would like to get it right and match actual hardware. My proposal
> >> >> > is
> >> >> > based on my understanding from the diagrams in the user manual.
> >> >>
> >> >> So for now, your explanation is the most reasonable. Should we go
> >> >> ahead
> >> >> and
> >> >> implement your idea?
> >> >>
> >> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
> >> >> one
> >> >> TV TCON instead of two of each kind. That means we will have hole in
> >> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> >> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> >> >> exactly the same.
> >> >
> >> > I just noticed issue with this proposal. If we have following clock
> >> > chain
> >> > for HDMI, everythings is ok:
> >> >
> >> > TCON-TV0 -> TCON-TOP-TV0
> >> >
> >> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
> >> > and
> >> > everything works.
> >> >
> >> > However, when TVE will be configured, it would look like this:
> >> >
> >> > TVE0 -> TCON-TOP-TV0
> >> >
> >> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> >> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
> >> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
> >> > see, same clock is set to two different rates by two different drivers.
> >> >
> >> > It *might* still work, since encoders set clock rate after TCON (at
> >> > least
> >> > that is my experience for HDMI pipeline), but that is still wrong.
> >> >
> >> > To overcome above issue, I would stick to original proposal with
> >> > additional
> >> > clock specified in TCON TV DT node. That way TCON driver would always
> >> > set
> >> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't
> >> > interfere
> >> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> >> > TCON-TOP mux.
> >> >
> >> > What do you think?
> >>
> >> I think this is the wrong representation, and worse, you are trying to
> >> work
> >> around software issues with it.
> >>
> >> So to confirm some details, the TVE expects 216 MHz clock, and it expects
> >> the TCON to run and output data at 216 MHz as well. Is that correct?
> >
> > Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC,
> > e.g. TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
> >
> >> Would any settings for the TCON differ between when HDMI or TVE is used?
> >
> > Apart of clock, no, other settings would be the same.
> >
> >> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of
> >> doubt
> >> it. It might be expecting 297 MHz for PC resolutions.
> >
> > Please check this table in BSP:
> > https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/driver
> > s/ video/sunxi/disp2/tv/drv_tv.c#L24
> >
> > 216 MHz is applicable for low resolution, interlaced modes. Modes like
> > 1080P, 1080I have expected standard timing.
>
> That's weird. So it only applies to SDTV video resolutions. I remember
> seeing an "up sampling" setting for composite in the TVE, which goes all
> the way up to 216 MHz. Maybe that's the reason?
>
Probably. If upsampling is set to 0, it still needs 27 MHz, which is 2x more
than standard PAL/NTSC clock. After studying AC200 manual (which is similar TV
encoder) and its driver, it seems the reason for that is 8 bit parallel
interface between TCON and TVE and 16 bit data (CCIR656).
However, actual tests would be needed to confirm all that.
> I wonder how the TCON manages this though. I mean with the dot clock this
> high, doesn't that mean the frame rate is much higher?
>
Not sure, but IMO it is downscaled somehow in TVE HW to get proper rates at
the end.
> >> I think these kinds of quirks should be handled in the software, instead
> >> of
> >> being papered over.
> >
> > Ok, that works for me too. I would just like to have such design that
> > would
> > later allow implementing TVE driver without much issues.
> >
> > BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel
> > clock at all, since it is controlled with TVE clock (same case as it
> > would be here, if TCON TOP mux is switched to TVE clock source).
>
> Does it require 216 MHz as well?
Yes. It supports only PAL and NTSC (only one DAC), so BSP driver sets TVE
clock to 216 MHz.
>
> > Maybe quirk can be added that it doesn't set clock rate at all if it is
> > connected to TVE?
>
> A quirk yes. But the dot clock would be 216 MHz instead of not setting it,
> and only for certain display modes. To be honest I think we can get by with
> just a TODO note for now.
Why not leave control of channel rate to TVE, since it knows if oversampling
is enabled or not? But that's debate for another time.
I will send new R40 HDMI patches according your original proposal.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 9:10 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 9:10 UTC (permalink / raw)
To: linux-sunxi, wens
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne ponedeljek, 25. junij 2018 ob 10:14:52 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:58 PM, Jernej =C5=A0krabec
>=20
> <jernej.skrabec@gmail.com> wrote:
> > Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai=20
napisal(a):
> >> On Mon, Jun 25, 2018 at 3:52 AM, Jernej =C5=A0krabec
> >>=20
> >> <jernej.skrabec@gmail.com> wrote:
> >> > Dne =C4=8Detrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej =C5=A0kr=
abec=20
napisal(a):
> >> >> Dne =C4=8Detrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai=20
napisal(a):
> >> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej =C5=A0krabec
> >> >> > <jernej.skrabec@siol.net>
> >> >>=20
> >> >> wrote:
> >> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
> >=20
> > napisal(a):
> >> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej =C5=A0krabec
> >> >> > >> <jernej.skrabec@siol.net>
> >> >> > >=20
> >> >> > > wrote:
> >> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >> >=20
> >> > napisal(a):
> >> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej =C5=A0krabec
> >> >> > >> >>=20
> >> >> > >> >> <jernej.skrabec@siol.net> wrote:
> >> >> > >> >> > Hi,
> >> >> > >> >> >=20
> >> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripa=
rd
> >> >>=20
> >> >> napisal(a):
> >> >> > >> >> >> Hi,
> >> >> > >> >> >>=20
> >> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
> >=20
> > wrote:
> >> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable addition=
al
> >> >> > >> >> >> > gate
> >> >> > >> >> >> > in
> >> >> > >> >> >> > order
> >> >> > >> >> >> > to work.
> >> >> > >> >> >> >=20
> >> >> > >> >> >> > Add support for such TCONs.
> >> >> > >> >> >> >=20
> >> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> >> > >> >> >> > ---
> >> >> > >> >> >> >=20
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> >> > >> >> >> >=20
> >> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > >> >> >> > 100644
> >> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> >> > >> >> >> > device
> >> >> > >> >> >> > *dev,
> >> >> > >> >> >> >=20
> >> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> >> > >> >> >> > =20
> >> >> > >> >> >> > }
> >> >> > >> >> >> >=20
> >> >> > >> >> >> > +
> >> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > >> >> >> > + tcon->top_clk =3D devm_clk_get(dev,
> >> >> > >> >> >> > "tcon-top");
> >> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON
> >> >> > >> >> >> > TOP
> >> >> > >> >> >> > bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > +
> >> >> > >> >> >>=20
> >> >> > >> >> >> Is it required for the TCON itself to operate, or does t=
he
> >> >> > >> >> >> TCON
> >> >> > >> >> >> requires the TCON TOP, which in turn requires that clock=
to
> >> >> > >> >> >> be
> >> >> > >> >> >> functional?
> >> >> > >> >> >>=20
> >> >> > >> >> >> I find it quite odd to have a clock that isn't meant for=
a
> >> >> > >> >> >> particular
> >> >> > >> >> >> device to actually be wired to another device. I'm not
> >> >> > >> >> >> saying
> >> >> > >> >> >> this
> >> >> > >> >> >> isn't the case, but it would be a first.
> >> >> > >> >> >=20
> >> >> > >> >> > Documentation doesn't say much about that gate. I did few
> >> >> > >> >> > tests
> >> >> > >> >> > and
> >> >> > >> >> > TCON
> >> >> > >> >> > registers can be read and written even if TCON TOP TV TCON
> >> >> > >> >> > gate
> >> >> > >> >> > is
> >> >> > >> >> > disabled. However, there is no image, as expected.
> >> >> > >> >>=20
> >> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> >> > >> >> There's
> >> >> > >> >> also
> >> >> > >> >> a
> >> >> > >> >> mux to select whether the clock comes directly from the CCU=
or
> >> >> > >> >> the
> >> >> > >> >> TV
> >> >> > >> >> encoder (a feedback mode?). I assume this is the gate you a=
re
> >> >> > >> >> referring
> >> >> > >> >> to
> >> >> > >> >> here, in which case it is not a bus clock, but rather the T=
CON
> >> >> > >> >> module
> >> >> > >> >> or
> >> >> > >> >> channel clock, strangely routed.
> >> >> > >> >>=20
> >> >> > >> >> > More interestingly, I enabled test pattern directly in TC=
ON
> >> >> > >> >> > to
> >> >> > >> >> > eliminate
> >> >> > >> >> > influence of the mixer. As soon as I disabled that gate,
> >> >> > >> >> > test
> >> >> > >> >> > pattern
> >> >> > >> >> > on
> >> >> > >> >> > HDMI screen was gone, which suggest that this gate
> >> >> > >> >> > influences
> >> >> > >> >> > something
> >> >> > >> >> > inside TCON.
> >> >> > >> >> >=20
> >> >> > >> >> > Another test I did was that I moved enable/disable gate c=
ode
> >> >> > >> >> > to
> >> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as wel=
l.
> >> >> > >> >> >=20
> >> >> > >> >> > I'll ask AW engineer what that gate actually does, but fr=
om
> >> >> > >> >> > what I
> >> >> > >> >> > saw,
> >> >> > >> >> > I
> >> >> > >> >> > would say that most appropriate location to enable/disable
> >> >> > >> >> > TCON
> >> >> > >> >> > TOP
> >> >> > >> >> > TV
> >> >> > >> >> > TCON
> >> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could
> >> >> > >> >> > check
> >> >> > >> >> > if
> >> >> > >> >> > any
> >> >> > >> >> > TV
> >> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> >> > >> >> > doesn't
> >> >> > >> >> > sound
> >> >> > >> >> > right to me for some reason.
> >> >> > >> >>=20
> >> >> > >> >> If what I said above it true, then yes, the appropriate
> >> >> > >> >> location
> >> >> > >> >> to
> >> >> > >> >> enable
> >> >> > >> >> it is the TCON driver, but moreover, the representation of =
the
> >> >> > >> >> clock
> >> >> > >> >> tree
> >> >> > >> >> should be fixed such that the TCON takes the clock from the
> >> >> > >> >> TCON
> >> >> > >> >> TOP
> >> >> > >> >> as
> >> >> > >> >> its
> >> >> > >> >> channel/ module clock instead. That way you don't need this
> >> >> > >> >> patch,
> >> >> > >> >> but
> >> >> > >> >> you'd add another for all the clock routing.
> >> >> > >> >=20
> >> >> > >> > Can you be more specific? I not sure what you mean here.
> >> >> > >>=20
> >> >> > >> For clock related properties in the device tree:
> >> >> > >>=20
> >> >> > >> &tcon_top {
> >> >> > >>=20
> >> >> > >> clocks =3D <&ccu CLK_BUS_TCON_TOP>,
> >> >> > >> =20
> >> >> > >> <&ccu CLK_TCON_TV0>,
> >> >> > >> <&tve0>,
> >> >> > >> <&ccu CLK_TCON_TV1>,
> >> >> > >> <&tve1>;
> >> >> > >> =20
> >> >> > >> clock-names =3D "bus", "tcon-tv0", "tve0", "tcon-tv1", "tv=
e1";
> >> >> > >> clock-output-names =3D "tcon-top-tv0", "tcon-top-tv1";
> >> >> > >>=20
> >> >> > >> };
> >> >> > >>=20
> >> >> > >> &tcon_tv0 {
> >> >> > >>=20
> >> >> > >> clocks =3D <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> >> > >> clock-names =3D "ahb", "tcon-ch1";
> >> >> > >>=20
> >> >> > >> };
> >> >> > >>=20
> >> >> > >> A diagram would look like:
> >> >> > >> | This part is TCON TOP |
> >> >> > >> =20
> >> >> > >> v v
> >> >> > >>=20
> >> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> >> > >>=20
> >> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> >> > >>=20
> >> >> > >> TVE0 --------------|----/ |
> >> >> > >>=20
> >> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> >> > >>=20
> >> >> > >> The user manual is a bit lacking on how TVE outputs a clock
> >> >> > >> though.
> >> >> > >=20
> >> >> > > I didn't yet received any response on HW details from AW till n=
ow,
> >> >> > > but I
> >> >> > > would like to post new version of patches soon.
> >> >> > >=20
> >> >> > > While chaining like you described could be implemented easily, I
> >> >> > > don't
> >> >> > > think it really represents HW as it is. Tests showed that these
> >> >> > > two
> >> >> > > clocks are independent, otherwise register writes/reads wouldn't
> >> >> > > be
> >> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clo=
ck
> >> >> > > as
> >> >> > > a
> >> >> > > parent becase if it is not enabled, it simply won't work.
> >> >> >=20
> >> >> > AFAIK with the TCONs, even when the TCON channel clock (not the b=
us
> >> >> > clock)
> >> >> > is disabled, register accesses still work.
> >> >>=20
> >> >> You're right, I just tested that.
> >> >>=20
> >> >> > I'm saying that the TCON TOP
> >> >> > gate is downstream from the TCON channel clock in the CCU. These =
are
> >> >> > not
> >> >> > related to the TCON bus clock in the CCU, which affects register
> >> >> > access.
> >> >> >=20
> >> >> > Did Allwinner provide any information regarding the hierarchy of =
the
> >> >> > clocks?
> >> >>=20
> >> >> No reponse for now.
> >> >>=20
> >> >> > > However, if everyone feels chaining is the best way to implement
> >> >> > > it,
> >> >> > > I'll
> >> >> > > do it.
> >> >> >=20
> >> >> > I would like to get it right and match actual hardware. My propos=
al
> >> >> > is
> >> >> > based on my understanding from the diagrams in the user manual.
> >> >>=20
> >> >> So for now, your explanation is the most reasonable. Should we go
> >> >> ahead
> >> >> and
> >> >> implement your idea?
> >> >>=20
> >> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON =
and
> >> >> one
> >> >> TV TCON instead of two of each kind. That means we will have hole in
> >> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) =
and
> >> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup =
is
> >> >> exactly the same.
> >> >=20
> >> > I just noticed issue with this proposal. If we have following clock
> >> > chain
> >> > for HDMI, everythings is ok:
> >> >=20
> >> > TCON-TV0 -> TCON-TOP-TV0
> >> >=20
> >> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 cl=
ock
> >> > and
> >> > everything works.
> >> >=20
> >> > However, when TVE will be configured, it would look like this:
> >> >=20
> >> > TVE0 -> TCON-TOP-TV0
> >> >=20
> >> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> >> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13=
=2E5
> >> > MHz (or whatever is the right clock rate for PAL and NTSC). As you c=
an
> >> > see, same clock is set to two different rates by two different drive=
rs.
> >> >=20
> >> > It *might* still work, since encoders set clock rate after TCON (at
> >> > least
> >> > that is my experience for HDMI pipeline), but that is still wrong.
> >> >=20
> >> > To overcome above issue, I would stick to original proposal with
> >> > additional
> >> > clock specified in TCON TV DT node. That way TCON driver would always
> >> > set
> >> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't
> >> > interfere
> >> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> >> > TCON-TOP mux.
> >> >=20
> >> > What do you think?
> >>=20
> >> I think this is the wrong representation, and worse, you are trying to
> >> work
> >> around software issues with it.
> >>=20
> >> So to confirm some details, the TVE expects 216 MHz clock, and it expe=
cts
> >> the TCON to run and output data at 216 MHz as well. Is that correct?
> >=20
> > Yes, from my understanding. 216 MHz is correct at least for PAL and NTS=
C,
> > e.g. TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
> >=20
> >> Would any settings for the TCON differ between when HDMI or TVE is use=
d?
> >=20
> > Apart of clock, no, other settings would be the same.
> >=20
> >> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of
> >> doubt
> >> it. It might be expecting 297 MHz for PC resolutions.
> >=20
> > Please check this table in BSP:
> > https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/dri=
ver
> > s/ video/sunxi/disp2/tv/drv_tv.c#L24
> >=20
> > 216 MHz is applicable for low resolution, interlaced modes. Modes like
> > 1080P, 1080I have expected standard timing.
>=20
> That's weird. So it only applies to SDTV video resolutions. I remember
> seeing an "up sampling" setting for composite in the TVE, which goes all
> the way up to 216 MHz. Maybe that's the reason?
>=20
Probably. If upsampling is set to 0, it still needs 27 MHz, which is 2x mor=
e=20
than standard PAL/NTSC clock. After studying AC200 manual (which is similar=
TV=20
encoder) and its driver, it seems the reason for that is 8 bit parallel=20
interface between TCON and TVE and 16 bit data (CCIR656).
However, actual tests would be needed to confirm all that.
> I wonder how the TCON manages this though. I mean with the dot clock this
> high, doesn't that mean the frame rate is much higher?
>=20
Not sure, but IMO it is downscaled somehow in TVE HW to get proper rates at=
=20
the end.
> >> I think these kinds of quirks should be handled in the software, inste=
ad
> >> of
> >> being papered over.
> >=20
> > Ok, that works for me too. I would just like to have such design that
> > would
> > later allow implementing TVE driver without much issues.
> >=20
> > BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel
> > clock at all, since it is controlled with TVE clock (same case as it
> > would be here, if TCON TOP mux is switched to TVE clock source).
>=20
> Does it require 216 MHz as well?
Yes. It supports only PAL and NTSC (only one DAC), so BSP driver sets TVE=20
clock to 216 MHz.
>=20
> > Maybe quirk can be added that it doesn't set clock rate at all if it is
> > connected to TVE?
>=20
> A quirk yes. But the dot clock would be 216 MHz instead of not setting it,
> and only for certain display modes. To be honest I think we can get by wi=
th
> just a TODO note for now.
Why not leave control of channel rate to TVE, since it knows if oversamplin=
g=20
is enabled or not? But that's debate for another time.
I will send new R40 HDMI patches according your original proposal.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
@ 2018-06-25 9:10 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-25 9:10 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, wens-jdAy2FN1RRM
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne ponedeljek, 25. junij 2018 ob 10:14:52 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 3:58 PM, Jernej Škrabec
>
> <jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Dne ponedeljek, 25. junij 2018 ob 05:51:41 CEST je Chen-Yu Tsai
napisal(a):
> >> On Mon, Jun 25, 2018 at 3:52 AM, Jernej Škrabec
> >>
> >> <jernej.skrabec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> > Dne četrtek, 21. junij 2018 ob 17:35:45 CEST je Jernej Škrabec
napisal(a):
> >> >> Dne četrtek, 21. junij 2018 ob 03:23:27 CEST je Chen-Yu Tsai
napisal(a):
> >> >> > On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec
> >> >> > <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> >>
> >> >> wrote:
> >> >> > > Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai
> >
> > napisal(a):
> >> >> > >> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> >> >> > >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> >> > >
> >> >> > > wrote:
> >> >> > >> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai
> >> >
> >> > napisal(a):
> >> >> > >> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
> >> >> > >> >>
> >> >> > >> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> >> >> > >> >> > Hi,
> >> >> > >> >> >
> >> >> > >> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard
> >> >>
> >> >> napisal(a):
> >> >> > >> >> >> Hi,
> >> >> > >> >> >>
> >> >> > >> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec
> >
> > wrote:
> >> >> > >> >> >> > TV TCONs connected to TCON TOP have to enable additional
> >> >> > >> >> >> > gate
> >> >> > >> >> >> > in
> >> >> > >> >> >> > order
> >> >> > >> >> >> > to work.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Add support for such TCONs.
> >> >> > >> >> >> >
> >> >> > >> >> >> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> >> > >> >> >> > ---
> >> >> > >> >> >> >
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++++++++++
> >> >> > >> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4 ++++
> >> >> > >> >> >> > 2 files changed, 15 insertions(+)
> >> >> > >> >> >> >
> >> >> > >> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
> >> >> > >> >> >> > 08747fc3ee71..0afb5a94a414
> >> >> > >> >> >> > 100644
> >> >> > >> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> >> > >> >> >> > @@ -688,6 +688,16 @@ static int
> >> >> > >> >> >> > sun4i_tcon_init_clocks(struct
> >> >> > >> >> >> > device
> >> >> > >> >> >> > *dev,
> >> >> > >> >> >> >
> >> >> > >> >> >> > dev_err(dev, "Couldn't get the TCON bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > return PTR_ERR(tcon->clk);
> >> >> > >> >> >> >
> >> >> > >> >> >> > }
> >> >> > >> >> >> >
> >> >> > >> >> >> > +
> >> >> > >> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
> >> >> > >> >> >> > + tcon->top_clk = devm_clk_get(dev,
> >> >> > >> >> >> > "tcon-top");
> >> >> > >> >> >> > + if (IS_ERR(tcon->top_clk)) {
> >> >> > >> >> >> > + dev_err(dev, "Couldn't get the TCON
> >> >> > >> >> >> > TOP
> >> >> > >> >> >> > bus
> >> >> > >> >> >> > clock\n");
> >> >> > >> >> >> > + return PTR_ERR(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > + clk_prepare_enable(tcon->top_clk);
> >> >> > >> >> >> > + }
> >> >> > >> >> >> > +
> >> >> > >> >> >>
> >> >> > >> >> >> Is it required for the TCON itself to operate, or does the
> >> >> > >> >> >> TCON
> >> >> > >> >> >> requires the TCON TOP, which in turn requires that clock to
> >> >> > >> >> >> be
> >> >> > >> >> >> functional?
> >> >> > >> >> >>
> >> >> > >> >> >> I find it quite odd to have a clock that isn't meant for a
> >> >> > >> >> >> particular
> >> >> > >> >> >> device to actually be wired to another device. I'm not
> >> >> > >> >> >> saying
> >> >> > >> >> >> this
> >> >> > >> >> >> isn't the case, but it would be a first.
> >> >> > >> >> >
> >> >> > >> >> > Documentation doesn't say much about that gate. I did few
> >> >> > >> >> > tests
> >> >> > >> >> > and
> >> >> > >> >> > TCON
> >> >> > >> >> > registers can be read and written even if TCON TOP TV TCON
> >> >> > >> >> > gate
> >> >> > >> >> > is
> >> >> > >> >> > disabled. However, there is no image, as expected.
> >> >> > >> >>
> >> >> > >> >> The R40 manual does include it in the diagram, on page 504.
> >> >> > >> >> There's
> >> >> > >> >> also
> >> >> > >> >> a
> >> >> > >> >> mux to select whether the clock comes directly from the CCU or
> >> >> > >> >> the
> >> >> > >> >> TV
> >> >> > >> >> encoder (a feedback mode?). I assume this is the gate you are
> >> >> > >> >> referring
> >> >> > >> >> to
> >> >> > >> >> here, in which case it is not a bus clock, but rather the TCON
> >> >> > >> >> module
> >> >> > >> >> or
> >> >> > >> >> channel clock, strangely routed.
> >> >> > >> >>
> >> >> > >> >> > More interestingly, I enabled test pattern directly in TCON
> >> >> > >> >> > to
> >> >> > >> >> > eliminate
> >> >> > >> >> > influence of the mixer. As soon as I disabled that gate,
> >> >> > >> >> > test
> >> >> > >> >> > pattern
> >> >> > >> >> > on
> >> >> > >> >> > HDMI screen was gone, which suggest that this gate
> >> >> > >> >> > influences
> >> >> > >> >> > something
> >> >> > >> >> > inside TCON.
> >> >> > >> >> >
> >> >> > >> >> > Another test I did was that I moved enable/disable gate code
> >> >> > >> >> > to
> >> >> > >> >> > sun4i_tcon_channel_set_status() and it worked just as well.
> >> >> > >> >> >
> >> >> > >> >> > I'll ask AW engineer what that gate actually does, but from
> >> >> > >> >> > what I
> >> >> > >> >> > saw,
> >> >> > >> >> > I
> >> >> > >> >> > would say that most appropriate location to enable/disable
> >> >> > >> >> > TCON
> >> >> > >> >> > TOP
> >> >> > >> >> > TV
> >> >> > >> >> > TCON
> >> >> > >> >> > gate is TCON driver. Alternatively, TCON TOP driver could
> >> >> > >> >> > check
> >> >> > >> >> > if
> >> >> > >> >> > any
> >> >> > >> >> > TV
> >> >> > >> >> > TCON is in use and enable appropriate gate. However, that
> >> >> > >> >> > doesn't
> >> >> > >> >> > sound
> >> >> > >> >> > right to me for some reason.
> >> >> > >> >>
> >> >> > >> >> If what I said above it true, then yes, the appropriate
> >> >> > >> >> location
> >> >> > >> >> to
> >> >> > >> >> enable
> >> >> > >> >> it is the TCON driver, but moreover, the representation of the
> >> >> > >> >> clock
> >> >> > >> >> tree
> >> >> > >> >> should be fixed such that the TCON takes the clock from the
> >> >> > >> >> TCON
> >> >> > >> >> TOP
> >> >> > >> >> as
> >> >> > >> >> its
> >> >> > >> >> channel/ module clock instead. That way you don't need this
> >> >> > >> >> patch,
> >> >> > >> >> but
> >> >> > >> >> you'd add another for all the clock routing.
> >> >> > >> >
> >> >> > >> > Can you be more specific? I not sure what you mean here.
> >> >> > >>
> >> >> > >> For clock related properties in the device tree:
> >> >> > >>
> >> >> > >> &tcon_top {
> >> >> > >>
> >> >> > >> clocks = <&ccu CLK_BUS_TCON_TOP>,
> >> >> > >>
> >> >> > >> <&ccu CLK_TCON_TV0>,
> >> >> > >> <&tve0>,
> >> >> > >> <&ccu CLK_TCON_TV1>,
> >> >> > >> <&tve1>;
> >> >> > >>
> >> >> > >> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
> >> >> > >> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
> >> >> > >>
> >> >> > >> };
> >> >> > >>
> >> >> > >> &tcon_tv0 {
> >> >> > >>
> >> >> > >> clocks = <&ccu CLK_BUS_TCON_TV0>, <&tcon_top 0>'
> >> >> > >> clock-names = "ahb", "tcon-ch1";
> >> >> > >>
> >> >> > >> };
> >> >> > >>
> >> >> > >> A diagram would look like:
> >> >> > >> | This part is TCON TOP |
> >> >> > >>
> >> >> > >> v v
> >> >> > >>
> >> >> > >> CCU CLK_TCON_TV0 --|----\ |
> >> >> > >>
> >> >> > >> | mux ---- gate ----|-- TCON_TV0
> >> >> > >>
> >> >> > >> TVE0 --------------|----/ |
> >> >> > >>
> >> >> > >> And the same goes for TCON_TV1 and TVE1.
> >> >> > >>
> >> >> > >> The user manual is a bit lacking on how TVE outputs a clock
> >> >> > >> though.
> >> >> > >
> >> >> > > I didn't yet received any response on HW details from AW till now,
> >> >> > > but I
> >> >> > > would like to post new version of patches soon.
> >> >> > >
> >> >> > > While chaining like you described could be implemented easily, I
> >> >> > > don't
> >> >> > > think it really represents HW as it is. Tests showed that these
> >> >> > > two
> >> >> > > clocks are independent, otherwise register writes/reads wouldn't
> >> >> > > be
> >> >> > > possible with tcon- top gate disabled. I chose tcon-top bus clock
> >> >> > > as
> >> >> > > a
> >> >> > > parent becase if it is not enabled, it simply won't work.
> >> >> >
> >> >> > AFAIK with the TCONs, even when the TCON channel clock (not the bus
> >> >> > clock)
> >> >> > is disabled, register accesses still work.
> >> >>
> >> >> You're right, I just tested that.
> >> >>
> >> >> > I'm saying that the TCON TOP
> >> >> > gate is downstream from the TCON channel clock in the CCU. These are
> >> >> > not
> >> >> > related to the TCON bus clock in the CCU, which affects register
> >> >> > access.
> >> >> >
> >> >> > Did Allwinner provide any information regarding the hierarchy of the
> >> >> > clocks?
> >> >>
> >> >> No reponse for now.
> >> >>
> >> >> > > However, if everyone feels chaining is the best way to implement
> >> >> > > it,
> >> >> > > I'll
> >> >> > > do it.
> >> >> >
> >> >> > I would like to get it right and match actual hardware. My proposal
> >> >> > is
> >> >> > based on my understanding from the diagrams in the user manual.
> >> >>
> >> >> So for now, your explanation is the most reasonable. Should we go
> >> >> ahead
> >> >> and
> >> >> implement your idea?
> >> >>
> >> >> Please note that H6 has TCON-TOP too, but it has only one LCD TCON and
> >> >> one
> >> >> TV TCON instead of two of each kind. That means we will have hole in
> >> >> indices (tcon_lcd0 is 1, tcon_tv0 is 3, which is aligned with R40) and
> >> >> different TCON- TOP binding (no tcon_tv1 channel clock), but setup is
> >> >> exactly the same.
> >> >
> >> > I just noticed issue with this proposal. If we have following clock
> >> > chain
> >> > for HDMI, everythings is ok:
> >> >
> >> > TCON-TV0 -> TCON-TOP-TV0
> >> >
> >> > TCON TV sets TCON-TOP-TV0 clock rate, which in turn sets TCON-TV0 clock
> >> > and
> >> > everything works.
> >> >
> >> > However, when TVE will be configured, it would look like this:
> >> >
> >> > TVE0 -> TCON-TOP-TV0
> >> >
> >> > TVE driver will set TVE0 clock to 216 MHz and TCON TV would set
> >> > TCON-TOP-TV0 rate which in turn sets TVE0 clock to something like 13.5
> >> > MHz (or whatever is the right clock rate for PAL and NTSC). As you can
> >> > see, same clock is set to two different rates by two different drivers.
> >> >
> >> > It *might* still work, since encoders set clock rate after TCON (at
> >> > least
> >> > that is my experience for HDMI pipeline), but that is still wrong.
> >> >
> >> > To overcome above issue, I would stick to original proposal with
> >> > additional
> >> > clock specified in TCON TV DT node. That way TCON driver would always
> >> > set
> >> > clock rate to TCON-TV0 clock. If TVE0 is enabled, TCON wouldn't
> >> > interfere
> >> > with setting clock rate, because TCON-TV0 clock would be decoupled in
> >> > TCON-TOP mux.
> >> >
> >> > What do you think?
> >>
> >> I think this is the wrong representation, and worse, you are trying to
> >> work
> >> around software issues with it.
> >>
> >> So to confirm some details, the TVE expects 216 MHz clock, and it expects
> >> the TCON to run and output data at 216 MHz as well. Is that correct?
> >
> > Yes, from my understanding. 216 MHz is correct at least for PAL and NTSC,
> > e.g. TV mode. TVE on R40 is also capable of RGB mode (VGA connector).
> >
> >> Would any settings for the TCON differ between when HDMI or TVE is used?
> >
> > Apart of clock, no, other settings would be the same.
> >
> >> Does TVE and TCON run at 216 MHz regardless of resolution? I kind of
> >> doubt
> >> it. It might be expecting 297 MHz for PC resolutions.
> >
> > Please check this table in BSP:
> > https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/driver
> > s/ video/sunxi/disp2/tv/drv_tv.c#L24
> >
> > 216 MHz is applicable for low resolution, interlaced modes. Modes like
> > 1080P, 1080I have expected standard timing.
>
> That's weird. So it only applies to SDTV video resolutions. I remember
> seeing an "up sampling" setting for composite in the TVE, which goes all
> the way up to 216 MHz. Maybe that's the reason?
>
Probably. If upsampling is set to 0, it still needs 27 MHz, which is 2x more
than standard PAL/NTSC clock. After studying AC200 manual (which is similar TV
encoder) and its driver, it seems the reason for that is 8 bit parallel
interface between TCON and TVE and 16 bit data (CCIR656).
However, actual tests would be needed to confirm all that.
> I wonder how the TCON manages this though. I mean with the dot clock this
> high, doesn't that mean the frame rate is much higher?
>
Not sure, but IMO it is downscaled somehow in TVE HW to get proper rates at
the end.
> >> I think these kinds of quirks should be handled in the software, instead
> >> of
> >> being papered over.
> >
> > Ok, that works for me too. I would just like to have such design that
> > would
> > later allow implementing TVE driver without much issues.
> >
> > BTW, H3 TV TCON which is connected to TVE doesn't have TCON-TV channel
> > clock at all, since it is controlled with TVE clock (same case as it
> > would be here, if TCON TOP mux is switched to TVE clock source).
>
> Does it require 216 MHz as well?
Yes. It supports only PAL and NTSC (only one DAC), so BSP driver sets TVE
clock to 216 MHz.
>
> > Maybe quirk can be added that it doesn't set clock rate at all if it is
> > connected to TVE?
>
> A quirk yes. But the dot clock would be 216 MHz instead of not setting it,
> and only for certain display modes. To be honest I think we can get by with
> just a TODO note for now.
Why not leave control of channel rate to TVE, since it knows if oversampling
is enabled or not? But that's debate for another time.
I will send new R40 HDMI patches according your original proposal.
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 12/27] drm/sun4i: tcon: Generalize engine search algorithm
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Current "old" method to find engine worked pretty well for DE2. However,
it doesn't work when TCON TOP is between mixer (engine) and TCON. TCON
TOP has multiple input ports, but current engine search algorithm
expects only one.
This can be fixed by first looking for output port id and selecting
matching input by subtracting 1 for the next round. This work even if
there is only one input and output.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0afb5a94a414..5dae623968f7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -802,12 +802,14 @@ static int sun4i_tcon_init_regmap(struct device *dev,
*/
static struct sunxi_engine *
sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
- struct device_node *node)
+ struct device_node *node,
+ u32 port_id)
{
struct device_node *port, *ep, *remote;
struct sunxi_engine *engine = ERR_PTR(-EINVAL);
+ u32 reg = 0;
- port = of_graph_get_port_by_id(node, 0);
+ port = of_graph_get_port_by_id(node, port_id);
if (!port)
return ERR_PTR(-EINVAL);
@@ -837,8 +839,20 @@ sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
if (remote == engine->node)
goto out_put_remote;
+ /*
+ * According to device tree binding input ports have even id
+ * number and output ports have odd id. Since component with
+ * more than one input and one output (TCON TOP) exits, correct
+ * remote input id has to be calculated by subtracting 1 from
+ * remote output id. If this for some reason can't be done, 0
+ * is used as input port id.
+ */
+ port = of_graph_get_remote_port(ep);
+ if (!of_property_read_u32(port, "reg", ®) && reg > 0)
+ reg -= 1;
+
/* keep looking through upstream ports */
- engine = sun4i_tcon_find_engine_traverse(drv, remote);
+ engine = sun4i_tcon_find_engine_traverse(drv, remote, reg);
out_put_remote:
of_node_put(remote);
@@ -961,7 +975,7 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,
/* Fallback to old method by traversing input endpoints */
of_node_put(port);
- return sun4i_tcon_find_engine_traverse(drv, node);
+ return sun4i_tcon_find_engine_traverse(drv, node, 0);
}
static int sun4i_tcon_bind(struct device *dev, struct device *master,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 12/27] drm/sun4i: tcon: Generalize engine search algorithm
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Current "old" method to find engine worked pretty well for DE2. However,
it doesn't work when TCON TOP is between mixer (engine) and TCON. TCON
TOP has multiple input ports, but current engine search algorithm
expects only one.
This can be fixed by first looking for output port id and selecting
matching input by subtracting 1 for the next round. This work even if
there is only one input and output.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0afb5a94a414..5dae623968f7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -802,12 +802,14 @@ static int sun4i_tcon_init_regmap(struct device *dev,
*/
static struct sunxi_engine *
sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
- struct device_node *node)
+ struct device_node *node,
+ u32 port_id)
{
struct device_node *port, *ep, *remote;
struct sunxi_engine *engine = ERR_PTR(-EINVAL);
+ u32 reg = 0;
- port = of_graph_get_port_by_id(node, 0);
+ port = of_graph_get_port_by_id(node, port_id);
if (!port)
return ERR_PTR(-EINVAL);
@@ -837,8 +839,20 @@ sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
if (remote == engine->node)
goto out_put_remote;
+ /*
+ * According to device tree binding input ports have even id
+ * number and output ports have odd id. Since component with
+ * more than one input and one output (TCON TOP) exits, correct
+ * remote input id has to be calculated by subtracting 1 from
+ * remote output id. If this for some reason can't be done, 0
+ * is used as input port id.
+ */
+ port = of_graph_get_remote_port(ep);
+ if (!of_property_read_u32(port, "reg", ®) && reg > 0)
+ reg -= 1;
+
/* keep looking through upstream ports */
- engine = sun4i_tcon_find_engine_traverse(drv, remote);
+ engine = sun4i_tcon_find_engine_traverse(drv, remote, reg);
out_put_remote:
of_node_put(remote);
@@ -961,7 +975,7 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,
/* Fallback to old method by traversing input endpoints */
of_node_put(port);
- return sun4i_tcon_find_engine_traverse(drv, node);
+ return sun4i_tcon_find_engine_traverse(drv, node, 0);
}
static int sun4i_tcon_bind(struct device *dev, struct device *master,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 12/27] drm/sun4i: tcon: Generalize engine search algorithm
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Current "old" method to find engine worked pretty well for DE2. However,
it doesn't work when TCON TOP is between mixer (engine) and TCON. TCON
TOP has multiple input ports, but current engine search algorithm
expects only one.
This can be fixed by first looking for output port id and selecting
matching input by subtracting 1 for the next round. This work even if
there is only one input and output.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0afb5a94a414..5dae623968f7 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -802,12 +802,14 @@ static int sun4i_tcon_init_regmap(struct device *dev,
*/
static struct sunxi_engine *
sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
- struct device_node *node)
+ struct device_node *node,
+ u32 port_id)
{
struct device_node *port, *ep, *remote;
struct sunxi_engine *engine = ERR_PTR(-EINVAL);
+ u32 reg = 0;
- port = of_graph_get_port_by_id(node, 0);
+ port = of_graph_get_port_by_id(node, port_id);
if (!port)
return ERR_PTR(-EINVAL);
@@ -837,8 +839,20 @@ sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
if (remote == engine->node)
goto out_put_remote;
+ /*
+ * According to device tree binding input ports have even id
+ * number and output ports have odd id. Since component with
+ * more than one input and one output (TCON TOP) exits, correct
+ * remote input id has to be calculated by subtracting 1 from
+ * remote output id. If this for some reason can't be done, 0
+ * is used as input port id.
+ */
+ port = of_graph_get_remote_port(ep);
+ if (!of_property_read_u32(port, "reg", ®) && reg > 0)
+ reg -= 1;
+
/* keep looking through upstream ports */
- engine = sun4i_tcon_find_engine_traverse(drv, remote);
+ engine = sun4i_tcon_find_engine_traverse(drv, remote, reg);
out_put_remote:
of_node_put(remote);
@@ -961,7 +975,7 @@ static struct sunxi_engine *sun4i_tcon_find_engine(struct sun4i_drv *drv,
/* Fallback to old method by traversing input endpoints */
of_node_put(port);
- return sun4i_tcon_find_engine_traverse(drv, node);
+ return sun4i_tcon_find_engine_traverse(drv, node, 0);
}
static int sun4i_tcon_bind(struct device *dev, struct device *master,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 13/27] drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
LVDS and RGB interfaces are always connected to TCONs which have channel
0. It doesn't make sense to try to init them on TV TCONs.
Add a check if TCON has channel 0 before trying to init LVDS or RGB
interface.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 32 ++++++++++++++++--------------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 5dae623968f7..b1205a7bc20f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1117,23 +1117,25 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
goto err_free_dotclock;
}
- /*
- * If we have an LVDS panel connected to the TCON, we should
- * just probe the LVDS connector. Otherwise, just probe RGB as
- * we used to.
- */
- remote = of_graph_get_remote_node(dev->of_node, 1, 0);
- if (of_device_is_compatible(remote, "panel-lvds"))
- if (can_lvds)
- ret = sun4i_lvds_init(drm, tcon);
+ if (tcon->quirks->has_channel_0) {
+ /*
+ * If we have an LVDS panel connected to the TCON, we should
+ * just probe the LVDS connector. Otherwise, just probe RGB as
+ * we used to.
+ */
+ remote = of_graph_get_remote_node(dev->of_node, 1, 0);
+ if (of_device_is_compatible(remote, "panel-lvds"))
+ if (can_lvds)
+ ret = sun4i_lvds_init(drm, tcon);
+ else
+ ret = -EINVAL;
else
- ret = -EINVAL;
- else
- ret = sun4i_rgb_init(drm, tcon);
- of_node_put(remote);
+ ret = sun4i_rgb_init(drm, tcon);
+ of_node_put(remote);
- if (ret < 0)
- goto err_free_dotclock;
+ if (ret < 0)
+ goto err_free_dotclock;
+ }
if (tcon->quirks->needs_de_be_mux) {
/*
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 13/27] drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
LVDS and RGB interfaces are always connected to TCONs which have channel
0. It doesn't make sense to try to init them on TV TCONs.
Add a check if TCON has channel 0 before trying to init LVDS or RGB
interface.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 32 ++++++++++++++++--------------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 5dae623968f7..b1205a7bc20f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1117,23 +1117,25 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
goto err_free_dotclock;
}
- /*
- * If we have an LVDS panel connected to the TCON, we should
- * just probe the LVDS connector. Otherwise, just probe RGB as
- * we used to.
- */
- remote = of_graph_get_remote_node(dev->of_node, 1, 0);
- if (of_device_is_compatible(remote, "panel-lvds"))
- if (can_lvds)
- ret = sun4i_lvds_init(drm, tcon);
+ if (tcon->quirks->has_channel_0) {
+ /*
+ * If we have an LVDS panel connected to the TCON, we should
+ * just probe the LVDS connector. Otherwise, just probe RGB as
+ * we used to.
+ */
+ remote = of_graph_get_remote_node(dev->of_node, 1, 0);
+ if (of_device_is_compatible(remote, "panel-lvds"))
+ if (can_lvds)
+ ret = sun4i_lvds_init(drm, tcon);
+ else
+ ret = -EINVAL;
else
- ret = -EINVAL;
- else
- ret = sun4i_rgb_init(drm, tcon);
- of_node_put(remote);
+ ret = sun4i_rgb_init(drm, tcon);
+ of_node_put(remote);
- if (ret < 0)
- goto err_free_dotclock;
+ if (ret < 0)
+ goto err_free_dotclock;
+ }
if (tcon->quirks->needs_de_be_mux) {
/*
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 13/27] drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
LVDS and RGB interfaces are always connected to TCONs which have channel
0. It doesn't make sense to try to init them on TV TCONs.
Add a check if TCON has channel 0 before trying to init LVDS or RGB
interface.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 32 ++++++++++++++++--------------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 5dae623968f7..b1205a7bc20f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1117,23 +1117,25 @@ static int sun4i_tcon_bind(struct device *dev, struct device *master,
goto err_free_dotclock;
}
- /*
- * If we have an LVDS panel connected to the TCON, we should
- * just probe the LVDS connector. Otherwise, just probe RGB as
- * we used to.
- */
- remote = of_graph_get_remote_node(dev->of_node, 1, 0);
- if (of_device_is_compatible(remote, "panel-lvds"))
- if (can_lvds)
- ret = sun4i_lvds_init(drm, tcon);
+ if (tcon->quirks->has_channel_0) {
+ /*
+ * If we have an LVDS panel connected to the TCON, we should
+ * just probe the LVDS connector. Otherwise, just probe RGB as
+ * we used to.
+ */
+ remote = of_graph_get_remote_node(dev->of_node, 1, 0);
+ if (of_device_is_compatible(remote, "panel-lvds"))
+ if (can_lvds)
+ ret = sun4i_lvds_init(drm, tcon);
+ else
+ ret = -EINVAL;
else
- ret = -EINVAL;
- else
- ret = sun4i_rgb_init(drm, tcon);
- of_node_put(remote);
+ ret = sun4i_rgb_init(drm, tcon);
+ of_node_put(remote);
- if (ret < 0)
- goto err_free_dotclock;
+ if (ret < 0)
+ goto err_free_dotclock;
+ }
if (tcon->quirks->needs_de_be_mux) {
/*
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
sense to check if panel or bridge is connected to them.
Check if TCON has channel 0 and only then check for connected panel or
bridges.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b1205a7bc20f..c9ffa5381185 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
static int sun4i_tcon_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
+ const struct sun4i_tcon_quirks *quirks;
struct drm_bridge *bridge;
struct drm_panel *panel;
int ret;
- ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
- if (ret == -EPROBE_DEFER)
- return ret;
+ quirks = of_device_get_match_data(&pdev->dev);
+
+ /* panels and bridges are present only on TCONs with channel 0 */
+ if (quirks->has_channel_0) {
+ ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ }
return component_add(&pdev->dev, &sun4i_tcon_ops);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
sense to check if panel or bridge is connected to them.
Check if TCON has channel 0 and only then check for connected panel or
bridges.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b1205a7bc20f..c9ffa5381185 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
static int sun4i_tcon_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
+ const struct sun4i_tcon_quirks *quirks;
struct drm_bridge *bridge;
struct drm_panel *panel;
int ret;
- ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
- if (ret == -EPROBE_DEFER)
- return ret;
+ quirks = of_device_get_match_data(&pdev->dev);
+
+ /* panels and bridges are present only on TCONs with channel 0 */
+ if (quirks->has_channel_0) {
+ ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ }
return component_add(&pdev->dev, &sun4i_tcon_ops);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
sense to check if panel or bridge is connected to them.
Check if TCON has channel 0 and only then check for connected panel or
bridges.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b1205a7bc20f..c9ffa5381185 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
static int sun4i_tcon_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
+ const struct sun4i_tcon_quirks *quirks;
struct drm_bridge *bridge;
struct drm_panel *panel;
int ret;
- ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
- if (ret == -EPROBE_DEFER)
- return ret;
+ quirks = of_device_get_match_data(&pdev->dev);
+
+ /* panels and bridges are present only on TCONs with channel 0 */
+ if (quirks->has_channel_0) {
+ ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ }
return component_add(&pdev->dev, &sun4i_tcon_ops);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 7:46 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:46 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens, robh+dt, airlied, gustavo, maarten.lankhorst, seanpaul,
mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> sense to check if panel or bridge is connected to them.
>
> Check if TCON has channel 0 and only then check for connected panel or
> bridges.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index b1205a7bc20f..c9ffa5381185 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
> static int sun4i_tcon_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> + const struct sun4i_tcon_quirks *quirks;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> int ret;
>
> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> - if (ret == -EPROBE_DEFER)
> - return ret;
> + quirks = of_device_get_match_data(&pdev->dev);
We should probably check ofr the pointer value before dereferencing it.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 7:46 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:46 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> sense to check if panel or bridge is connected to them.
>
> Check if TCON has channel 0 and only then check for connected panel or
> bridges.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index b1205a7bc20f..c9ffa5381185 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
> static int sun4i_tcon_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> + const struct sun4i_tcon_quirks *quirks;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> int ret;
>
> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> - if (ret == -EPROBE_DEFER)
> - return ret;
> + quirks = of_device_get_match_data(&pdev->dev);
We should probably check ofr the pointer value before dereferencing it.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/86d5ae0a/attachment-0001.sig>
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 7:46 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:46 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> sense to check if panel or bridge is connected to them.
>
> Check if TCON has channel 0 and only then check for connected panel or
> bridges.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> index b1205a7bc20f..c9ffa5381185 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
> static int sun4i_tcon_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> + const struct sun4i_tcon_quirks *quirks;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> int ret;
>
> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> - if (ret == -EPROBE_DEFER)
> - return ret;
> + quirks = of_device_get_match_data(&pdev->dev);
We should probably check ofr the pointer value before dereferencing it.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
2018-06-13 7:46 ` Maxime Ripard
(?)
@ 2018-06-13 8:04 ` Chen-Yu Tsai
-1 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 8:04 UTC (permalink / raw)
To: Maxime Ripard
Cc: Jernej Skrabec, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
>> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
>> sense to check if panel or bridge is connected to them.
>>
>> Check if TCON has channel 0 and only then check for connected panel or
>> bridges.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index b1205a7bc20f..c9ffa5381185 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
>> static int sun4i_tcon_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> + const struct sun4i_tcon_quirks *quirks;
>> struct drm_bridge *bridge;
>> struct drm_panel *panel;
>> int ret;
>>
>> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
>> - if (ret == -EPROBE_DEFER)
>> - return ret;
>> + quirks = of_device_get_match_data(&pdev->dev);
>
> We should probably check ofr the pointer value before dereferencing it.
I think we've discussed this before. If the driver has data structures
for all the supported compatible strings, and it is device tree only,
then we should just let it blow up in the user's face, since they are
obviously doing something they shouldn't be doing to get the driver
to probe without a compatible string match.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 8:04 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 8:04 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
>> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
>> sense to check if panel or bridge is connected to them.
>>
>> Check if TCON has channel 0 and only then check for connected panel or
>> bridges.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index b1205a7bc20f..c9ffa5381185 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
>> static int sun4i_tcon_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> + const struct sun4i_tcon_quirks *quirks;
>> struct drm_bridge *bridge;
>> struct drm_panel *panel;
>> int ret;
>>
>> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
>> - if (ret == -EPROBE_DEFER)
>> - return ret;
>> + quirks = of_device_get_match_data(&pdev->dev);
>
> We should probably check ofr the pointer value before dereferencing it.
I think we've discussed this before. If the driver has data structures
for all the supported compatible strings, and it is device tree only,
then we should just let it blow up in the user's face, since they are
obviously doing something they shouldn't be doing to get the driver
to probe without a compatible string match.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 8:04 ` Chen-Yu Tsai
0 siblings, 0 replies; 201+ messages in thread
From: Chen-Yu Tsai @ 2018-06-13 8:04 UTC (permalink / raw)
To: Maxime Ripard
Cc: Jernej Skrabec, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
<maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
>> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
>> sense to check if panel or bridge is connected to them.
>>
>> Check if TCON has channel 0 and only then check for connected panel or
>> bridges.
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
>> ---
>> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> index b1205a7bc20f..c9ffa5381185 100644
>> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops = {
>> static int sun4i_tcon_probe(struct platform_device *pdev)
>> {
>> struct device_node *node = pdev->dev.of_node;
>> + const struct sun4i_tcon_quirks *quirks;
>> struct drm_bridge *bridge;
>> struct drm_panel *panel;
>> int ret;
>>
>> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
>> - if (ret == -EPROBE_DEFER)
>> - return ret;
>> + quirks = of_device_get_match_data(&pdev->dev);
>
> We should probably check ofr the pointer value before dereferencing it.
I think we've discussed this before. If the driver has data structures
for all the supported compatible strings, and it is device tree only,
then we should just let it blow up in the user's face, since they are
obviously doing something they shouldn't be doing to get the driver
to probe without a compatible string match.
ChenYu
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: [linux-sunxi] Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 16:20 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:20 UTC (permalink / raw)
To: linux-sunxi, wens
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne sreda, 13. junij 2018 ob 10:04:20 CEST je Chen-Yu Tsai napisal(a):
> On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
>
> <maxime.ripard@bootlin.com> wrote:
> > On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> >> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> >> sense to check if panel or bridge is connected to them.
> >>
> >> Check if TCON has channel 0 and only then check for connected panel or
> >> bridges.
> >>
> >> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> ---
> >>
> >> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
> >> 1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> b/drivers/gpu/drm/sun4i/sun4i_tcon.c index b1205a7bc20f..c9ffa5381185
> >> 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops
> >> = {>>
> >> static int sun4i_tcon_probe(struct platform_device *pdev)
> >> {
> >>
> >> struct device_node *node = pdev->dev.of_node;
> >>
> >> + const struct sun4i_tcon_quirks *quirks;
> >>
> >> struct drm_bridge *bridge;
> >> struct drm_panel *panel;
> >> int ret;
> >>
> >> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> >> - if (ret == -EPROBE_DEFER)
> >> - return ret;
> >> + quirks = of_device_get_match_data(&pdev->dev);
> >
> > We should probably check ofr the pointer value before dereferencing it.
>
> I think we've discussed this before. If the driver has data structures
> for all the supported compatible strings, and it is device tree only,
> then we should just let it blow up in the user's face, since they are
> obviously doing something they shouldn't be doing to get the driver
> to probe without a compatible string match.
TCON can't work with no quirks specified, since that would mean that neither
channels are present. Additionally, sun4i_tcon_bind() also doesn't check if
quirks are NULL or not. So I concur with Chen-Yu here.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* [linux-sunxi] Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 16:20 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:20 UTC (permalink / raw)
To: linux-arm-kernel
Dne sreda, 13. junij 2018 ob 10:04:20 CEST je Chen-Yu Tsai napisal(a):
> On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
>
> <maxime.ripard@bootlin.com> wrote:
> > On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> >> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> >> sense to check if panel or bridge is connected to them.
> >>
> >> Check if TCON has channel 0 and only then check for connected panel or
> >> bridges.
> >>
> >> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> >> ---
> >>
> >> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
> >> 1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> b/drivers/gpu/drm/sun4i/sun4i_tcon.c index b1205a7bc20f..c9ffa5381185
> >> 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops
> >> = {>>
> >> static int sun4i_tcon_probe(struct platform_device *pdev)
> >> {
> >>
> >> struct device_node *node = pdev->dev.of_node;
> >>
> >> + const struct sun4i_tcon_quirks *quirks;
> >>
> >> struct drm_bridge *bridge;
> >> struct drm_panel *panel;
> >> int ret;
> >>
> >> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> >> - if (ret == -EPROBE_DEFER)
> >> - return ret;
> >> + quirks = of_device_get_match_data(&pdev->dev);
> >
> > We should probably check ofr the pointer value before dereferencing it.
>
> I think we've discussed this before. If the driver has data structures
> for all the supported compatible strings, and it is device tree only,
> then we should just let it blow up in the user's face, since they are
> obviously doing something they shouldn't be doing to get the driver
> to probe without a compatible string match.
TCON can't work with no quirks specified, since that would mean that neither
channels are present. Additionally, sun4i_tcon_bind() also doesn't check if
quirks are NULL or not. So I concur with Chen-Yu here.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread* Re: Re: [PATCH v2 14/27] drm/sun4i: Don't check for panel or bridge on TV TCONs
@ 2018-06-13 16:20 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:20 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, wens-jdAy2FN1RRM
Cc: Maxime Ripard, Rob Herring, David Airlie, Gustavo Padovan,
Maarten Lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk
Dne sreda, 13. junij 2018 ob 10:04:20 CEST je Chen-Yu Tsai napisal(a):
> On Wed, Jun 13, 2018 at 3:46 PM, Maxime Ripard
>
> <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > On Tue, Jun 12, 2018 at 10:00:23PM +0200, Jernej Skrabec wrote:
> >> TV TCONs are always connected to TV or HDMI encoder, so it doesn't make
> >> sense to check if panel or bridge is connected to them.
> >>
> >> Check if TCON has channel 0 and only then check for connected panel or
> >> bridges.
> >>
> >> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> ---
> >>
> >> drivers/gpu/drm/sun4i/sun4i_tcon.c | 12 +++++++++---
> >> 1 file changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> b/drivers/gpu/drm/sun4i/sun4i_tcon.c index b1205a7bc20f..c9ffa5381185
> >> 100644
> >> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> >> @@ -1189,13 +1189,19 @@ static const struct component_ops sun4i_tcon_ops
> >> = {>>
> >> static int sun4i_tcon_probe(struct platform_device *pdev)
> >> {
> >>
> >> struct device_node *node = pdev->dev.of_node;
> >>
> >> + const struct sun4i_tcon_quirks *quirks;
> >>
> >> struct drm_bridge *bridge;
> >> struct drm_panel *panel;
> >> int ret;
> >>
> >> - ret = drm_of_find_panel_or_bridge(node, 1, 0, &panel, &bridge);
> >> - if (ret == -EPROBE_DEFER)
> >> - return ret;
> >> + quirks = of_device_get_match_data(&pdev->dev);
> >
> > We should probably check ofr the pointer value before dereferencing it.
>
> I think we've discussed this before. If the driver has data structures
> for all the supported compatible strings, and it is device tree only,
> then we should just let it blow up in the user's face, since they are
> obviously doing something they shouldn't be doing to get the driver
> to probe without a compatible string match.
TCON can't work with no quirks specified, since that would mean that neither
channels are present. Additionally, sun4i_tcon_bind() also doesn't check if
quirks are NULL or not. So I concur with Chen-Yu here.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 15/27] drm/sun4i: Add support for R40 TV TCON
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
R40 TV TCON is similar to the A83T TV TCON, except that it needs
additional gate to be enabled.
Add support for it.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c9ffa5381185..f20da2aa2165 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1326,6 +1326,11 @@ static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
.has_channel_1 = true,
};
+static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
+ .has_channel_1 = true,
+ .has_tcon_top_gate = true,
+};
+
static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
.has_channel_0 = true,
};
@@ -1350,6 +1355,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data = &sun8i_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-tv", .data = &sun8i_a83t_tv_quirks },
+ { .compatible = "allwinner,sun8i-r40-tcon-tv", .data = &sun8i_r40_tv_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data = &sun9i_a80_tcon_lcd_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-tv", .data = &sun9i_a80_tcon_tv_quirks },
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 15/27] drm/sun4i: Add support for R40 TV TCON
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
R40 TV TCON is similar to the A83T TV TCON, except that it needs
additional gate to be enabled.
Add support for it.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c9ffa5381185..f20da2aa2165 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1326,6 +1326,11 @@ static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
.has_channel_1 = true,
};
+static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
+ .has_channel_1 = true,
+ .has_tcon_top_gate = true,
+};
+
static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
.has_channel_0 = true,
};
@@ -1350,6 +1355,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data = &sun8i_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-tv", .data = &sun8i_a83t_tv_quirks },
+ { .compatible = "allwinner,sun8i-r40-tcon-tv", .data = &sun8i_r40_tv_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data = &sun9i_a80_tcon_lcd_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-tv", .data = &sun9i_a80_tcon_tv_quirks },
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 15/27] drm/sun4i: Add support for R40 TV TCON
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
R40 TV TCON is similar to the A83T TV TCON, except that it needs
additional gate to be enabled.
Add support for it.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index c9ffa5381185..f20da2aa2165 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1326,6 +1326,11 @@ static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
.has_channel_1 = true,
};
+static const struct sun4i_tcon_quirks sun8i_r40_tv_quirks = {
+ .has_channel_1 = true,
+ .has_tcon_top_gate = true,
+};
+
static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
.has_channel_0 = true,
};
@@ -1350,6 +1355,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data = &sun8i_a83t_lcd_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-tv", .data = &sun8i_a83t_tv_quirks },
+ { .compatible = "allwinner,sun8i-r40-tcon-tv", .data = &sun8i_r40_tv_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-lcd", .data = &sun9i_a80_tcon_lcd_quirks },
{ .compatible = "allwinner,sun9i-a80-tcon-tv", .data = &sun9i_a80_tcon_tv_quirks },
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
R40 DE2 mixers are similar to those found in A83T, except it needs
different clock settings.
Add a compatibles for them.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 68c4b2995624..d84df6d808c2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -358,6 +358,8 @@ Required properties:
* allwinner,sun8i-a83t-de2-mixer-0
* allwinner,sun8i-a83t-de2-mixer-1
* allwinner,sun8i-h3-de2-mixer-0
+ * allwinner,sun8i-r40-de2-mixer-0
+ * allwinner,sun8i-r40-de2-mixer-1
* allwinner,sun8i-v3s-de2-mixer
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the mixer
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
R40 DE2 mixers are similar to those found in A83T, except it needs
different clock settings.
Add a compatibles for them.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 68c4b2995624..d84df6d808c2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -358,6 +358,8 @@ Required properties:
* allwinner,sun8i-a83t-de2-mixer-0
* allwinner,sun8i-a83t-de2-mixer-1
* allwinner,sun8i-h3-de2-mixer-0
+ * allwinner,sun8i-r40-de2-mixer-0
+ * allwinner,sun8i-r40-de2-mixer-1
* allwinner,sun8i-v3s-de2-mixer
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the mixer
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
R40 DE2 mixers are similar to those found in A83T, except it needs
different clock settings.
Add a compatibles for them.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index 68c4b2995624..d84df6d808c2 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -358,6 +358,8 @@ Required properties:
* allwinner,sun8i-a83t-de2-mixer-0
* allwinner,sun8i-a83t-de2-mixer-1
* allwinner,sun8i-h3-de2-mixer-0
+ * allwinner,sun8i-r40-de2-mixer-0
+ * allwinner,sun8i-r40-de2-mixer-1
* allwinner,sun8i-v3s-de2-mixer
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the mixer
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
2018-06-12 20:00 ` Jernej Skrabec
(?)
@ 2018-06-20 19:16 ` Rob Herring
-1 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:16 UTC (permalink / raw)
To: Jernej Skrabec
Cc: maxime.ripard, wens, airlied, gustavo, maarten.lankhorst,
seanpaul, mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
On Tue, Jun 12, 2018 at 10:00:25PM +0200, Jernej Skrabec wrote:
> R40 DE2 mixers are similar to those found in A83T, except it needs
> different clock settings.
>
> Add a compatibles for them.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
@ 2018-06-20 19:16 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:16 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 12, 2018 at 10:00:25PM +0200, Jernej Skrabec wrote:
> R40 DE2 mixers are similar to those found in A83T, except it needs
> different clock settings.
>
> Add a compatibles for them.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
@ 2018-06-20 19:16 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:16 UTC (permalink / raw)
To: Jernej Skrabec
Cc: mark.rutland, devicetree, maxime.ripard, linux-sunxi,
linux-kernel, dri-devel, airlied, wens, linux-clk,
linux-arm-kernel
On Tue, Jun 12, 2018 at 10:00:25PM +0200, Jernej Skrabec wrote:
> R40 DE2 mixers are similar to those found in A83T, except it needs
> different clock settings.
>
> Add a compatibles for them.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 17/27] drm/sun4i: Add support for R40 mixers
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Both mixers have similar capabilities as others SoCs with DE2.
First mixer has 1 VI and 3 UI planes and supports HW scaling on all
planes.
Second mixer has 1 VI and 1 UI planes and also supports HW scaling on
all planes.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 126899d6f0d3..ee8febb25903 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -500,6 +500,22 @@ static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_r40_mixer0_cfg = {
+ .ccsc = 0,
+ .mod_rate = 297000000,
+ .scaler_mask = 0xf,
+ .ui_num = 3,
+ .vi_num = 1,
+};
+
+static const struct sun8i_mixer_cfg sun8i_r40_mixer1_cfg = {
+ .ccsc = 1,
+ .mod_rate = 297000000,
+ .scaler_mask = 0x3,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -521,6 +537,14 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-h3-de2-mixer-0",
.data = &sun8i_h3_mixer0_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-0",
+ .data = &sun8i_r40_mixer0_cfg,
+ },
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-1",
+ .data = &sun8i_r40_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 17/27] drm/sun4i: Add support for R40 mixers
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Both mixers have similar capabilities as others SoCs with DE2.
First mixer has 1 VI and 3 UI planes and supports HW scaling on all
planes.
Second mixer has 1 VI and 1 UI planes and also supports HW scaling on
all planes.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 126899d6f0d3..ee8febb25903 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -500,6 +500,22 @@ static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_r40_mixer0_cfg = {
+ .ccsc = 0,
+ .mod_rate = 297000000,
+ .scaler_mask = 0xf,
+ .ui_num = 3,
+ .vi_num = 1,
+};
+
+static const struct sun8i_mixer_cfg sun8i_r40_mixer1_cfg = {
+ .ccsc = 1,
+ .mod_rate = 297000000,
+ .scaler_mask = 0x3,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -521,6 +537,14 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-h3-de2-mixer-0",
.data = &sun8i_h3_mixer0_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-0",
+ .data = &sun8i_r40_mixer0_cfg,
+ },
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-1",
+ .data = &sun8i_r40_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 17/27] drm/sun4i: Add support for R40 mixers
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Both mixers have similar capabilities as others SoCs with DE2.
First mixer has 1 VI and 3 UI planes and supports HW scaling on all
planes.
Second mixer has 1 VI and 1 UI planes and also supports HW scaling on
all planes.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 126899d6f0d3..ee8febb25903 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -500,6 +500,22 @@ static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_r40_mixer0_cfg = {
+ .ccsc = 0,
+ .mod_rate = 297000000,
+ .scaler_mask = 0xf,
+ .ui_num = 3,
+ .vi_num = 1,
+};
+
+static const struct sun8i_mixer_cfg sun8i_r40_mixer1_cfg = {
+ .ccsc = 1,
+ .mod_rate = 297000000,
+ .scaler_mask = 0x3,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -521,6 +537,14 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-h3-de2-mixer-0",
.data = &sun8i_h3_mixer0_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-0",
+ .data = &sun8i_r40_mixer0_cfg,
+ },
+ {
+ .compatible = "allwinner,sun8i-r40-de2-mixer-1",
+ .data = &sun8i_r40_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
clock parents. It is compatible to other HDMI PHYs, like that found in
R40.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index d84df6d808c2..6fb45c7a9ac8 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -101,6 +101,7 @@ DWC HDMI PHY
Required properties:
- compatible: value must be one of:
+ * allwinner,sun50i-a64-hdmi-phy
* allwinner,sun8i-a83t-hdmi-phy
* allwinner,sun8i-h3-hdmi-phy
- reg: base address and size of memory-mapped region
@@ -111,8 +112,9 @@ Required properties:
- resets: phandle to the reset controller driving the PHY
- reset-names: must be "phy"
-H3 HDMI PHY requires additional clock:
+H3 and A64 HDMI PHY require additional clocks:
- pll-0: parent of phy clock
+ - pll-1: second possible phy clock parent (A64 only)
TV Encoder
----------
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
clock parents. It is compatible to other HDMI PHYs, like that found in
R40.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index d84df6d808c2..6fb45c7a9ac8 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -101,6 +101,7 @@ DWC HDMI PHY
Required properties:
- compatible: value must be one of:
+ * allwinner,sun50i-a64-hdmi-phy
* allwinner,sun8i-a83t-hdmi-phy
* allwinner,sun8i-h3-hdmi-phy
- reg: base address and size of memory-mapped region
@@ -111,8 +112,9 @@ Required properties:
- resets: phandle to the reset controller driving the PHY
- reset-names: must be "phy"
-H3 HDMI PHY requires additional clock:
+H3 and A64 HDMI PHY require additional clocks:
- pll-0: parent of phy clock
+ - pll-1: second possible phy clock parent (A64 only)
TV Encoder
----------
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
clock parents. It is compatible to other HDMI PHYs, like that found in
R40.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
index d84df6d808c2..6fb45c7a9ac8 100644
--- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
+++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
@@ -101,6 +101,7 @@ DWC HDMI PHY
Required properties:
- compatible: value must be one of:
+ * allwinner,sun50i-a64-hdmi-phy
* allwinner,sun8i-a83t-hdmi-phy
* allwinner,sun8i-h3-hdmi-phy
- reg: base address and size of memory-mapped region
@@ -111,8 +112,9 @@ Required properties:
- resets: phandle to the reset controller driving the PHY
- reset-names: must be "phy"
-H3 HDMI PHY requires additional clock:
+H3 and A64 HDMI PHY require additional clocks:
- pll-0: parent of phy clock
+ - pll-1: second possible phy clock parent (A64 only)
TV Encoder
----------
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
@ 2018-06-20 19:17 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:17 UTC (permalink / raw)
To: Jernej Skrabec
Cc: maxime.ripard, wens, airlied, gustavo, maarten.lankhorst,
seanpaul, mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
On Tue, Jun 12, 2018 at 10:00:27PM +0200, Jernej Skrabec wrote:
> A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
> clock parents. It is compatible to other HDMI PHYs, like that found in
> R40.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
@ 2018-06-20 19:17 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:17 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 12, 2018 at 10:00:27PM +0200, Jernej Skrabec wrote:
> A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
> clock parents. It is compatible to other HDMI PHYs, like that found in
> R40.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
@ 2018-06-20 19:17 ` Rob Herring
0 siblings, 0 replies; 201+ messages in thread
From: Rob Herring @ 2018-06-20 19:17 UTC (permalink / raw)
To: Jernej Skrabec
Cc: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
On Tue, Jun 12, 2018 at 10:00:27PM +0200, Jernej Skrabec wrote:
> A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL
> clock parents. It is compatible to other HDMI PHYs, like that found in
> R40.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 19/27] drm/sun4i: Enable DW HDMI PHY clock
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Current DW HDMI PHY code never prepares and enables PHY clock after it is
created. It's just used as it is. This may work in some cases, but it's
clearly wrong. Fix it by adding proper calls to enable/disable PHY
clock.
Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 5a52fc489a9d..966688f04741 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -477,13 +477,15 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll0;
}
+
+ clk_prepare_enable(phy->clk_phy);
}
phy->rst_phy = of_reset_control_get_shared(node, "phy");
if (IS_ERR(phy->rst_phy)) {
dev_err(dev, "Could not get phy reset control\n");
ret = PTR_ERR(phy->rst_phy);
- goto err_put_clk_pll0;
+ goto err_disable_clk_phy;
}
ret = reset_control_deassert(phy->rst_phy);
@@ -514,6 +516,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_assert(phy->rst_phy);
err_put_rst_phy:
reset_control_put(phy->rst_phy);
+err_disable_clk_phy:
+ clk_disable_unprepare(phy->clk_phy);
err_put_clk_pll0:
if (phy->variant->has_phy_clk)
clk_put(phy->clk_pll0);
@@ -531,6 +535,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
clk_disable_unprepare(phy->clk_mod);
clk_disable_unprepare(phy->clk_bus);
+ clk_disable_unprepare(phy->clk_phy);
reset_control_assert(phy->rst_phy);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 19/27] drm/sun4i: Enable DW HDMI PHY clock
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Current DW HDMI PHY code never prepares and enables PHY clock after it is
created. It's just used as it is. This may work in some cases, but it's
clearly wrong. Fix it by adding proper calls to enable/disable PHY
clock.
Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 5a52fc489a9d..966688f04741 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -477,13 +477,15 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll0;
}
+
+ clk_prepare_enable(phy->clk_phy);
}
phy->rst_phy = of_reset_control_get_shared(node, "phy");
if (IS_ERR(phy->rst_phy)) {
dev_err(dev, "Could not get phy reset control\n");
ret = PTR_ERR(phy->rst_phy);
- goto err_put_clk_pll0;
+ goto err_disable_clk_phy;
}
ret = reset_control_deassert(phy->rst_phy);
@@ -514,6 +516,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_assert(phy->rst_phy);
err_put_rst_phy:
reset_control_put(phy->rst_phy);
+err_disable_clk_phy:
+ clk_disable_unprepare(phy->clk_phy);
err_put_clk_pll0:
if (phy->variant->has_phy_clk)
clk_put(phy->clk_pll0);
@@ -531,6 +535,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
clk_disable_unprepare(phy->clk_mod);
clk_disable_unprepare(phy->clk_bus);
+ clk_disable_unprepare(phy->clk_phy);
reset_control_assert(phy->rst_phy);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 19/27] drm/sun4i: Enable DW HDMI PHY clock
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Current DW HDMI PHY code never prepares and enables PHY clock after it is
created. It's just used as it is. This may work in some cases, but it's
clearly wrong. Fix it by adding proper calls to enable/disable PHY
clock.
Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 5a52fc489a9d..966688f04741 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -477,13 +477,15 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll0;
}
+
+ clk_prepare_enable(phy->clk_phy);
}
phy->rst_phy = of_reset_control_get_shared(node, "phy");
if (IS_ERR(phy->rst_phy)) {
dev_err(dev, "Could not get phy reset control\n");
ret = PTR_ERR(phy->rst_phy);
- goto err_put_clk_pll0;
+ goto err_disable_clk_phy;
}
ret = reset_control_deassert(phy->rst_phy);
@@ -514,6 +516,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_assert(phy->rst_phy);
err_put_rst_phy:
reset_control_put(phy->rst_phy);
+err_disable_clk_phy:
+ clk_disable_unprepare(phy->clk_phy);
err_put_clk_pll0:
if (phy->variant->has_phy_clk)
clk_put(phy->clk_pll0);
@@ -531,6 +535,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
clk_disable_unprepare(phy->clk_mod);
clk_disable_unprepare(phy->clk_bus);
+ clk_disable_unprepare(phy->clk_phy);
reset_control_assert(phy->rst_phy);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
DW HDMI PHY driver and PHY clock driver share same registers. Make sure
that DW HDMI PHY setup code doesn't change any clock related bits and
set them to 0 during initialization.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 79154f0f674a..3ba71aff92fc 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -98,7 +98,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
-#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 966688f04741..cd07ceb71601 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi *hdmi,
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
- regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
+ /*
+ * NOTE: We have to be careful not to overwrite PHY parent
+ * clock selection bit and clock divider.
+ */
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ pll_cfg1_init);
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
(u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
pll_cfg2_init);
@@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct sun8i_hdmi_phy *phy)
SUN8I_HDMI_PHY_ANA_CFG3_SCLEN |
SUN8I_HDMI_PHY_ANA_CFG3_SDAEN);
+ /* reset PLL clock configuration */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0);
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0);
+
/* set HW control of CEC pins */
regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
DW HDMI PHY driver and PHY clock driver share same registers. Make sure
that DW HDMI PHY setup code doesn't change any clock related bits and
set them to 0 during initialization.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 79154f0f674a..3ba71aff92fc 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -98,7 +98,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
-#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 966688f04741..cd07ceb71601 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi *hdmi,
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
- regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
+ /*
+ * NOTE: We have to be careful not to overwrite PHY parent
+ * clock selection bit and clock divider.
+ */
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ pll_cfg1_init);
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
(u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
pll_cfg2_init);
@@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct sun8i_hdmi_phy *phy)
SUN8I_HDMI_PHY_ANA_CFG3_SCLEN |
SUN8I_HDMI_PHY_ANA_CFG3_SDAEN);
+ /* reset PLL clock configuration */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0);
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0);
+
/* set HW control of CEC pins */
regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
DW HDMI PHY driver and PHY clock driver share same registers. Make sure
that DW HDMI PHY setup code doesn't change any clock related bits and
set them to 0 during initialization.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 79154f0f674a..3ba71aff92fc 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -98,7 +98,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
-#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index 966688f04741..cd07ceb71601 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi *hdmi,
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
- regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
+ /*
+ * NOTE: We have to be careful not to overwrite PHY parent
+ * clock selection bit and clock divider.
+ */
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ pll_cfg1_init);
regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
(u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
pll_cfg2_init);
@@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct sun8i_hdmi_phy *phy)
SUN8I_HDMI_PHY_ANA_CFG3_SCLEN |
SUN8I_HDMI_PHY_ANA_CFG3_SDAEN);
+ /* reset PLL clock configuration */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0);
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0);
+
/* set HW control of CEC pins */
regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
@ 2018-06-15 16:44 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 16:44 UTC (permalink / raw)
To: linux-sunxi
Cc: maxime.ripard, wens, robh+dt, airlied, gustavo,
maarten.lankhorst, seanpaul, mark.rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk
Dne torek, 12. junij 2018 ob 22:00:29 CEST je Jernej Skrabec napisal(a):
> DW HDMI PHY driver and PHY clock driver share same registers. Make sure
> that DW HDMI PHY setup code doesn't change any clock related bits and
> set them to 0 during initialization.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..3ba71aff92fc
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> @@ -98,7 +98,7 @@
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
> -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 966688f04741..cd07ceb71601
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
> *hdmi, regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
> SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
>
> - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
> + /*
> + * NOTE: We have to be careful not to overwrite PHY parent
> + * clock selection bit and clock divider.
> + */
> + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> + pll_cfg1_init);
> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
> (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
> pll_cfg2_init);
> @@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct
> sun8i_hdmi_phy *phy) SUN8I_HDMI_PHY_ANA_CFG3_SCLEN |
> SUN8I_HDMI_PHY_ANA_CFG3_SDAEN);
>
> + /* reset PLL clock configuration */
> + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0);
> + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0);
> +
For some reason, this change breaks HDMI on H3. Clearing only PLL parent
selection bit works ok, though. I'll fix it in next revision.
Best regards,
Jernej
> /* set HW control of CEC pins */
> regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
@ 2018-06-15 16:44 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 16:44 UTC (permalink / raw)
To: linux-arm-kernel
Dne torek, 12. junij 2018 ob 22:00:29 CEST je Jernej Skrabec napisal(a):
> DW HDMI PHY driver and PHY clock driver share same registers. Make sure
> that DW HDMI PHY setup code doesn't change any clock related bits and
> set them to 0 during initialization.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..3ba71aff92fc
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> @@ -98,7 +98,7 @@
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
> -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 966688f04741..cd07ceb71601
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
> *hdmi, regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
> SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
>
> - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
> + /*
> + * NOTE: We have to be careful not to overwrite PHY parent
> + * clock selection bit and clock divider.
> + */
> + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> + pll_cfg1_init);
> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
> (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
> pll_cfg2_init);
> @@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct
> sun8i_hdmi_phy *phy) SUN8I_HDMI_PHY_ANA_CFG3_SCLEN |
> SUN8I_HDMI_PHY_ANA_CFG3_SDAEN);
>
> + /* reset PLL clock configuration */
> + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0);
> + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0);
> +
For some reason, this change breaks HDMI on H3. Clearing only PLL parent
selection bit works ok, though. I'll fix it in next revision.
Best regards,
Jernej
> /* set HW control of CEC pins */
> regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 20/27] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
@ 2018-06-15 16:44 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-15 16:44 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Cc: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, airlied-cv59FeDIM0c,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA
Dne torek, 12. junij 2018 ob 22:00:29 CEST je Jernej Skrabec napisal(a):
> DW HDMI PHY driver and PHY clock driver share same registers. Make sure
> that DW HDMI PHY setup code doesn't change any clock related bits and
> set them to 0 during initialization.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 +++++++++++-
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h index 79154f0f674a..3ba71aff92fc
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> @@ -98,7 +98,7 @@
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_EN BIT(29)
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
> #define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
> -#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL BIT(26)
> +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
> #define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
> #define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
> #define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 966688f04741..cd07ceb71601
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> @@ -183,7 +183,13 @@ static int sun8i_hdmi_phy_config_h3(struct dw_hdmi
> *hdmi, regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_ANA_CFG1_REG,
> SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK, 0);
>
> - regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, pll_cfg1_init);
> + /*
> + * NOTE: We have to be careful not to overwrite PHY parent
> + * clock selection bit and clock divider.
> + */
> + regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> + (u32)~SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
> + pll_cfg1_init);
> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG,
> (u32)~SUN8I_HDMI_PHY_PLL_CFG2_PREDIV_MSK,
> pll_cfg2_init);
> @@ -352,6 +358,10 @@ static void sun8i_hdmi_phy_init_h3(struct
> sun8i_hdmi_phy *phy) SUN8I_HDMI_PHY_ANA_CFG3_SCLEN |
> SUN8I_HDMI_PHY_ANA_CFG3_SDAEN);
>
> + /* reset PLL clock configuration */
> + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, 0);
> + regmap_write(phy->regs, SUN8I_HDMI_PHY_PLL_CFG2_REG, 0);
> +
For some reason, this change breaks HDMI on H3. Clearing only PLL parent
selection bit works ok, though. I'll fix it in next revision.
Best regards,
Jernej
> /* set HW control of CEC pins */
> regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 21/27] drm/sun4i: DW HDMI PHY: Add support for second PLL
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Some DW HDMI PHYs, like those found in A64 and R40 SoCs, can select
between two clock parents.
Add code which reads second PLL from DT.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 ++
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 20 +++++++++++++++-----
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 3ba71aff92fc..46a3aa6a53a9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -147,6 +147,7 @@ struct sun8i_hdmi_phy;
struct sun8i_hdmi_phy_variant {
bool has_phy_clk;
+ bool has_second_pll;
void (*phy_init)(struct sun8i_hdmi_phy *phy);
void (*phy_disable)(struct dw_hdmi *hdmi,
struct sun8i_hdmi_phy *phy);
@@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
struct clk *clk_mod;
struct clk *clk_phy;
struct clk *clk_pll0;
+ struct clk *clk_pll1;
unsigned int rcal;
struct regmap *regs;
struct reset_control *rst_phy;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index cd07ceb71601..f50072ae054a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -482,10 +482,19 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
goto err_put_clk_mod;
}
+ if (phy->variant->has_second_pll) {
+ phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
+ if (IS_ERR(phy->clk_pll1)) {
+ dev_err(dev, "Could not get pll-1 clock\n");
+ ret = PTR_ERR(phy->clk_pll1);
+ goto err_put_clk_pll0;
+ }
+ }
+
ret = sun8i_phy_clk_create(phy, dev);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
- goto err_put_clk_pll0;
+ goto err_put_clk_pll1;
}
clk_prepare_enable(phy->clk_phy);
@@ -528,9 +537,10 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_put(phy->rst_phy);
err_disable_clk_phy:
clk_disable_unprepare(phy->clk_phy);
+err_put_clk_pll1:
+ clk_put(phy->clk_pll1);
err_put_clk_pll0:
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
err_put_clk_mod:
clk_put(phy->clk_mod);
err_put_clk_bus:
@@ -551,8 +561,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
reset_control_put(phy->rst_phy);
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll1);
clk_put(phy->clk_mod);
clk_put(phy->clk_bus);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 21/27] drm/sun4i: DW HDMI PHY: Add support for second PLL
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Some DW HDMI PHYs, like those found in A64 and R40 SoCs, can select
between two clock parents.
Add code which reads second PLL from DT.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 ++
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 20 +++++++++++++++-----
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 3ba71aff92fc..46a3aa6a53a9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -147,6 +147,7 @@ struct sun8i_hdmi_phy;
struct sun8i_hdmi_phy_variant {
bool has_phy_clk;
+ bool has_second_pll;
void (*phy_init)(struct sun8i_hdmi_phy *phy);
void (*phy_disable)(struct dw_hdmi *hdmi,
struct sun8i_hdmi_phy *phy);
@@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
struct clk *clk_mod;
struct clk *clk_phy;
struct clk *clk_pll0;
+ struct clk *clk_pll1;
unsigned int rcal;
struct regmap *regs;
struct reset_control *rst_phy;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index cd07ceb71601..f50072ae054a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -482,10 +482,19 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
goto err_put_clk_mod;
}
+ if (phy->variant->has_second_pll) {
+ phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
+ if (IS_ERR(phy->clk_pll1)) {
+ dev_err(dev, "Could not get pll-1 clock\n");
+ ret = PTR_ERR(phy->clk_pll1);
+ goto err_put_clk_pll0;
+ }
+ }
+
ret = sun8i_phy_clk_create(phy, dev);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
- goto err_put_clk_pll0;
+ goto err_put_clk_pll1;
}
clk_prepare_enable(phy->clk_phy);
@@ -528,9 +537,10 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_put(phy->rst_phy);
err_disable_clk_phy:
clk_disable_unprepare(phy->clk_phy);
+err_put_clk_pll1:
+ clk_put(phy->clk_pll1);
err_put_clk_pll0:
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
err_put_clk_mod:
clk_put(phy->clk_mod);
err_put_clk_bus:
@@ -551,8 +561,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
reset_control_put(phy->rst_phy);
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll1);
clk_put(phy->clk_mod);
clk_put(phy->clk_bus);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 21/27] drm/sun4i: DW HDMI PHY: Add support for second PLL
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Some DW HDMI PHYs, like those found in A64 and R40 SoCs, can select
between two clock parents.
Add code which reads second PLL from DT.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 ++
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 20 +++++++++++++++-----
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 3ba71aff92fc..46a3aa6a53a9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -147,6 +147,7 @@ struct sun8i_hdmi_phy;
struct sun8i_hdmi_phy_variant {
bool has_phy_clk;
+ bool has_second_pll;
void (*phy_init)(struct sun8i_hdmi_phy *phy);
void (*phy_disable)(struct dw_hdmi *hdmi,
struct sun8i_hdmi_phy *phy);
@@ -160,6 +161,7 @@ struct sun8i_hdmi_phy {
struct clk *clk_mod;
struct clk *clk_phy;
struct clk *clk_pll0;
+ struct clk *clk_pll1;
unsigned int rcal;
struct regmap *regs;
struct reset_control *rst_phy;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index cd07ceb71601..f50072ae054a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -482,10 +482,19 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
goto err_put_clk_mod;
}
+ if (phy->variant->has_second_pll) {
+ phy->clk_pll1 = of_clk_get_by_name(node, "pll-1");
+ if (IS_ERR(phy->clk_pll1)) {
+ dev_err(dev, "Could not get pll-1 clock\n");
+ ret = PTR_ERR(phy->clk_pll1);
+ goto err_put_clk_pll0;
+ }
+ }
+
ret = sun8i_phy_clk_create(phy, dev);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
- goto err_put_clk_pll0;
+ goto err_put_clk_pll1;
}
clk_prepare_enable(phy->clk_phy);
@@ -528,9 +537,10 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
reset_control_put(phy->rst_phy);
err_disable_clk_phy:
clk_disable_unprepare(phy->clk_phy);
+err_put_clk_pll1:
+ clk_put(phy->clk_pll1);
err_put_clk_pll0:
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
err_put_clk_mod:
clk_put(phy->clk_mod);
err_put_clk_bus:
@@ -551,8 +561,8 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
reset_control_put(phy->rst_phy);
- if (phy->variant->has_phy_clk)
- clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll0);
+ clk_put(phy->clk_pll1);
clk_put(phy->clk_mod);
clk_put(phy->clk_bus);
}
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 22/27] drm/sun4i: Add support for second clock parent to DW HDMI PHY clk driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Expand HDMI PHY clock driver to support second clock parent.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 4 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 ++++++++++++++++------
3 files changed, 73 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 46a3aa6a53a9..aadbe0a10b0c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -99,6 +99,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
@@ -190,6 +191,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent);
#endif /* _SUN8I_DW_HDMI_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index f50072ae054a..e1b7196d4587 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -491,7 +491,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
}
}
- ret = sun8i_phy_clk_create(phy, dev);
+ ret = sun8i_phy_clk_create(phy, dev,
+ phy->variant->has_second_pll);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll1;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
index faea449812f8..a4d31fe3abff 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
@@ -22,35 +22,45 @@ static int sun8i_phy_clk_determine_rate(struct clk_hw *hw,
{
unsigned long rate = req->rate;
unsigned long best_rate = 0;
+ struct clk_hw *best_parent = NULL;
struct clk_hw *parent;
int best_div = 1;
- int i;
+ int i, p;
- parent = clk_hw_get_parent(hw);
-
- for (i = 1; i <= 16; i++) {
- unsigned long ideal = rate * i;
- unsigned long rounded;
-
- rounded = clk_hw_round_rate(parent, ideal);
+ for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
+ parent = clk_hw_get_parent_by_index(hw, p);
+ if (!parent)
+ continue;
- if (rounded == ideal) {
- best_rate = rounded;
- best_div = i;
- break;
+ for (i = 1; i <= 16; i++) {
+ unsigned long ideal = rate * i;
+ unsigned long rounded;
+
+ rounded = clk_hw_round_rate(parent, ideal);
+
+ if (rounded == ideal) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ break;
+ }
+
+ if (!best_rate ||
+ abs(rate - rounded / i) <
+ abs(rate - best_rate / best_div)) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ }
}
- if (!best_rate ||
- abs(rate - rounded / i) <
- abs(rate - best_rate / best_div)) {
- best_rate = rounded;
- best_div = i;
- }
+ if (best_rate / best_div == rate)
+ break;
}
req->rate = best_rate / best_div;
req->best_parent_rate = best_rate;
- req->best_parent_hw = parent;
+ req->best_parent_hw = best_parent;
return 0;
}
@@ -95,22 +105,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw *hw, unsigned long rate,
return 0;
}
+static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+ u32 reg;
+
+ regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
+ reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
+
+ return reg;
+}
+
+static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+
+ if (index > 1)
+ return -EINVAL;
+
+ regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
+
+ return 0;
+}
+
static const struct clk_ops sun8i_phy_clk_ops = {
.determine_rate = sun8i_phy_clk_determine_rate,
.recalc_rate = sun8i_phy_clk_recalc_rate,
.set_rate = sun8i_phy_clk_set_rate,
+
+ .get_parent = sun8i_phy_clk_get_parent,
+ .set_parent = sun8i_phy_clk_set_parent,
};
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent)
{
struct clk_init_data init;
struct sun8i_phy_clk *priv;
- const char *parents[1];
+ const char *parents[2];
parents[0] = __clk_get_name(phy->clk_pll0);
if (!parents[0])
return -ENODEV;
+ if (second_parent) {
+ parents[1] = __clk_get_name(phy->clk_pll1);
+ if (!parents[1])
+ return -ENODEV;
+ }
+
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -118,7 +164,7 @@ int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
init.name = "hdmi-phy-clk";
init.ops = &sun8i_phy_clk_ops;
init.parent_names = parents;
- init.num_parents = 1;
+ init.num_parents = second_parent ? 2 : 1;
init.flags = CLK_SET_RATE_PARENT;
priv->phy = phy;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 22/27] drm/sun4i: Add support for second clock parent to DW HDMI PHY clk driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Expand HDMI PHY clock driver to support second clock parent.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 4 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 ++++++++++++++++------
3 files changed, 73 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 46a3aa6a53a9..aadbe0a10b0c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -99,6 +99,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
@@ -190,6 +191,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent);
#endif /* _SUN8I_DW_HDMI_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index f50072ae054a..e1b7196d4587 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -491,7 +491,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
}
}
- ret = sun8i_phy_clk_create(phy, dev);
+ ret = sun8i_phy_clk_create(phy, dev,
+ phy->variant->has_second_pll);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll1;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
index faea449812f8..a4d31fe3abff 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
@@ -22,35 +22,45 @@ static int sun8i_phy_clk_determine_rate(struct clk_hw *hw,
{
unsigned long rate = req->rate;
unsigned long best_rate = 0;
+ struct clk_hw *best_parent = NULL;
struct clk_hw *parent;
int best_div = 1;
- int i;
+ int i, p;
- parent = clk_hw_get_parent(hw);
-
- for (i = 1; i <= 16; i++) {
- unsigned long ideal = rate * i;
- unsigned long rounded;
-
- rounded = clk_hw_round_rate(parent, ideal);
+ for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
+ parent = clk_hw_get_parent_by_index(hw, p);
+ if (!parent)
+ continue;
- if (rounded == ideal) {
- best_rate = rounded;
- best_div = i;
- break;
+ for (i = 1; i <= 16; i++) {
+ unsigned long ideal = rate * i;
+ unsigned long rounded;
+
+ rounded = clk_hw_round_rate(parent, ideal);
+
+ if (rounded == ideal) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ break;
+ }
+
+ if (!best_rate ||
+ abs(rate - rounded / i) <
+ abs(rate - best_rate / best_div)) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ }
}
- if (!best_rate ||
- abs(rate - rounded / i) <
- abs(rate - best_rate / best_div)) {
- best_rate = rounded;
- best_div = i;
- }
+ if (best_rate / best_div == rate)
+ break;
}
req->rate = best_rate / best_div;
req->best_parent_rate = best_rate;
- req->best_parent_hw = parent;
+ req->best_parent_hw = best_parent;
return 0;
}
@@ -95,22 +105,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw *hw, unsigned long rate,
return 0;
}
+static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+ u32 reg;
+
+ regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
+ reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
+
+ return reg;
+}
+
+static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+
+ if (index > 1)
+ return -EINVAL;
+
+ regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
+
+ return 0;
+}
+
static const struct clk_ops sun8i_phy_clk_ops = {
.determine_rate = sun8i_phy_clk_determine_rate,
.recalc_rate = sun8i_phy_clk_recalc_rate,
.set_rate = sun8i_phy_clk_set_rate,
+
+ .get_parent = sun8i_phy_clk_get_parent,
+ .set_parent = sun8i_phy_clk_set_parent,
};
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent)
{
struct clk_init_data init;
struct sun8i_phy_clk *priv;
- const char *parents[1];
+ const char *parents[2];
parents[0] = __clk_get_name(phy->clk_pll0);
if (!parents[0])
return -ENODEV;
+ if (second_parent) {
+ parents[1] = __clk_get_name(phy->clk_pll1);
+ if (!parents[1])
+ return -ENODEV;
+ }
+
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -118,7 +164,7 @@ int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
init.name = "hdmi-phy-clk";
init.ops = &sun8i_phy_clk_ops;
init.parent_names = parents;
- init.num_parents = 1;
+ init.num_parents = second_parent ? 2 : 1;
init.flags = CLK_SET_RATE_PARENT;
priv->phy = phy;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 22/27] drm/sun4i: Add support for second clock parent to DW HDMI PHY clk driver
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Expand HDMI PHY clock driver to support second clock parent.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 4 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 3 +-
drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c | 90 ++++++++++++++++------
3 files changed, 73 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index 46a3aa6a53a9..aadbe0a10b0c 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -99,6 +99,7 @@
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_EN BIT(28)
#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27)
#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26)
+#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26
#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25)
#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x) ((x) << 22)
#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20)
@@ -190,6 +191,7 @@ void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev);
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent);
#endif /* _SUN8I_DW_HDMI_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index f50072ae054a..e1b7196d4587 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -491,7 +491,8 @@ int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
}
}
- ret = sun8i_phy_clk_create(phy, dev);
+ ret = sun8i_phy_clk_create(phy, dev,
+ phy->variant->has_second_pll);
if (ret) {
dev_err(dev, "Couldn't create the PHY clock\n");
goto err_put_clk_pll1;
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
index faea449812f8..a4d31fe3abff 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy_clk.c
@@ -22,35 +22,45 @@ static int sun8i_phy_clk_determine_rate(struct clk_hw *hw,
{
unsigned long rate = req->rate;
unsigned long best_rate = 0;
+ struct clk_hw *best_parent = NULL;
struct clk_hw *parent;
int best_div = 1;
- int i;
+ int i, p;
- parent = clk_hw_get_parent(hw);
-
- for (i = 1; i <= 16; i++) {
- unsigned long ideal = rate * i;
- unsigned long rounded;
-
- rounded = clk_hw_round_rate(parent, ideal);
+ for (p = 0; p < clk_hw_get_num_parents(hw); p++) {
+ parent = clk_hw_get_parent_by_index(hw, p);
+ if (!parent)
+ continue;
- if (rounded == ideal) {
- best_rate = rounded;
- best_div = i;
- break;
+ for (i = 1; i <= 16; i++) {
+ unsigned long ideal = rate * i;
+ unsigned long rounded;
+
+ rounded = clk_hw_round_rate(parent, ideal);
+
+ if (rounded == ideal) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ break;
+ }
+
+ if (!best_rate ||
+ abs(rate - rounded / i) <
+ abs(rate - best_rate / best_div)) {
+ best_rate = rounded;
+ best_div = i;
+ best_parent = parent;
+ }
}
- if (!best_rate ||
- abs(rate - rounded / i) <
- abs(rate - best_rate / best_div)) {
- best_rate = rounded;
- best_div = i;
- }
+ if (best_rate / best_div == rate)
+ break;
}
req->rate = best_rate / best_div;
req->best_parent_rate = best_rate;
- req->best_parent_hw = parent;
+ req->best_parent_hw = best_parent;
return 0;
}
@@ -95,22 +105,58 @@ static int sun8i_phy_clk_set_rate(struct clk_hw *hw, unsigned long rate,
return 0;
}
+static u8 sun8i_phy_clk_get_parent(struct clk_hw *hw)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+ u32 reg;
+
+ regmap_read(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG, ®);
+ reg = (reg & SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK) >>
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT;
+
+ return reg;
+}
+
+static int sun8i_phy_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct sun8i_phy_clk *priv = hw_to_phy_clk(hw);
+
+ if (index > 1)
+ return -EINVAL;
+
+ regmap_update_bits(priv->phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
+ SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK,
+ index << SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT);
+
+ return 0;
+}
+
static const struct clk_ops sun8i_phy_clk_ops = {
.determine_rate = sun8i_phy_clk_determine_rate,
.recalc_rate = sun8i_phy_clk_recalc_rate,
.set_rate = sun8i_phy_clk_set_rate,
+
+ .get_parent = sun8i_phy_clk_get_parent,
+ .set_parent = sun8i_phy_clk_set_parent,
};
-int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
+int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev,
+ bool second_parent)
{
struct clk_init_data init;
struct sun8i_phy_clk *priv;
- const char *parents[1];
+ const char *parents[2];
parents[0] = __clk_get_name(phy->clk_pll0);
if (!parents[0])
return -ENODEV;
+ if (second_parent) {
+ parents[1] = __clk_get_name(phy->clk_pll1);
+ if (!parents[1])
+ return -ENODEV;
+ }
+
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -118,7 +164,7 @@ int sun8i_phy_clk_create(struct sun8i_hdmi_phy *phy, struct device *dev)
init.name = "hdmi-phy-clk";
init.ops = &sun8i_phy_clk_ops;
init.parent_names = parents;
- init.num_parents = 1;
+ init.num_parents = second_parent ? 2 : 1;
init.flags = CLK_SET_RATE_PARENT;
priv->phy = phy;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 23/27] drm/sun4i: Add support for A64 HDMI PHY
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
PHY is the same as in H3, except it can switch between two clock
parents.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index e1b7196d4587..457f0a121684 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -396,6 +396,14 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config = {
.name = "phy"
};
+static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
+ .has_phy_clk = true,
+ .has_second_pll = true,
+ .phy_init = &sun8i_hdmi_phy_init_h3,
+ .phy_disable = &sun8i_hdmi_phy_disable_h3,
+ .phy_config = &sun8i_hdmi_phy_config_h3,
+};
+
static const struct sun8i_hdmi_phy_variant sun8i_a83t_hdmi_phy = {
.phy_init = &sun8i_hdmi_phy_init_a83t,
.phy_disable = &sun8i_hdmi_phy_disable_a83t,
@@ -410,6 +418,10 @@ static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
};
static const struct of_device_id sun8i_hdmi_phy_of_table[] = {
+ {
+ .compatible = "allwinner,sun50i-a64-hdmi-phy",
+ .data = &sun50i_a64_hdmi_phy,
+ },
{
.compatible = "allwinner,sun8i-a83t-hdmi-phy",
.data = &sun8i_a83t_hdmi_phy,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 23/27] drm/sun4i: Add support for A64 HDMI PHY
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
PHY is the same as in H3, except it can switch between two clock
parents.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index e1b7196d4587..457f0a121684 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -396,6 +396,14 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config = {
.name = "phy"
};
+static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
+ .has_phy_clk = true,
+ .has_second_pll = true,
+ .phy_init = &sun8i_hdmi_phy_init_h3,
+ .phy_disable = &sun8i_hdmi_phy_disable_h3,
+ .phy_config = &sun8i_hdmi_phy_config_h3,
+};
+
static const struct sun8i_hdmi_phy_variant sun8i_a83t_hdmi_phy = {
.phy_init = &sun8i_hdmi_phy_init_a83t,
.phy_disable = &sun8i_hdmi_phy_disable_a83t,
@@ -410,6 +418,10 @@ static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
};
static const struct of_device_id sun8i_hdmi_phy_of_table[] = {
+ {
+ .compatible = "allwinner,sun50i-a64-hdmi-phy",
+ .data = &sun50i_a64_hdmi_phy,
+ },
{
.compatible = "allwinner,sun8i-a83t-hdmi-phy",
.data = &sun8i_a83t_hdmi_phy,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 23/27] drm/sun4i: Add support for A64 HDMI PHY
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
PHY is the same as in H3, except it can switch between two clock
parents.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
index e1b7196d4587..457f0a121684 100644
--- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -396,6 +396,14 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config = {
.name = "phy"
};
+static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = {
+ .has_phy_clk = true,
+ .has_second_pll = true,
+ .phy_init = &sun8i_hdmi_phy_init_h3,
+ .phy_disable = &sun8i_hdmi_phy_disable_h3,
+ .phy_config = &sun8i_hdmi_phy_config_h3,
+};
+
static const struct sun8i_hdmi_phy_variant sun8i_a83t_hdmi_phy = {
.phy_init = &sun8i_hdmi_phy_init_a83t,
.phy_disable = &sun8i_hdmi_phy_disable_a83t,
@@ -410,6 +418,10 @@ static const struct sun8i_hdmi_phy_variant sun8i_h3_hdmi_phy = {
};
static const struct of_device_id sun8i_hdmi_phy_of_table[] = {
+ {
+ .compatible = "allwinner,sun50i-a64-hdmi-phy",
+ .data = &sun50i_a64_hdmi_phy,
+ },
{
.compatible = "allwinner,sun8i-a83t-hdmi-phy",
.data = &sun8i_a83t_hdmi_phy,
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Function is useful when drm_of_find_possible_crtcs() can't be used and
custom parsing is needed. This can happen for example when there is a
node with multiple muxes between crtc and encoder.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/drm_of.c | 4 ++--
include/drm/drm_of.h | 8 ++++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 1fe122461298..2e9cea3287b2 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
* Given a port OF node, return the possible mask of the corresponding
* CRTC within a device's list of CRTCs. Returns zero if not found.
*/
-static uint32_t drm_crtc_port_mask(struct drm_device *dev,
- struct device_node *port)
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
{
unsigned int index = 0;
struct drm_crtc *tmp;
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index b93c239afb60..a61fd77e46ba 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -17,6 +17,8 @@ struct drm_bridge;
struct device_node;
#ifdef CONFIG_OF
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port);
uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port);
void drm_of_component_match_add(struct device *master,
@@ -34,6 +36,12 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
struct drm_panel **panel,
struct drm_bridge **bridge);
#else
+static inline uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
+{
+ return 0;
+}
+
static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port)
{
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Function is useful when drm_of_find_possible_crtcs() can't be used and
custom parsing is needed. This can happen for example when there is a
node with multiple muxes between crtc and encoder.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/drm_of.c | 4 ++--
include/drm/drm_of.h | 8 ++++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 1fe122461298..2e9cea3287b2 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
* Given a port OF node, return the possible mask of the corresponding
* CRTC within a device's list of CRTCs. Returns zero if not found.
*/
-static uint32_t drm_crtc_port_mask(struct drm_device *dev,
- struct device_node *port)
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
{
unsigned int index = 0;
struct drm_crtc *tmp;
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index b93c239afb60..a61fd77e46ba 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -17,6 +17,8 @@ struct drm_bridge;
struct device_node;
#ifdef CONFIG_OF
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port);
uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port);
void drm_of_component_match_add(struct device *master,
@@ -34,6 +36,12 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
struct drm_panel **panel,
struct drm_bridge **bridge);
#else
+static inline uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
+{
+ return 0;
+}
+
static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port)
{
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Function is useful when drm_of_find_possible_crtcs() can't be used and
custom parsing is needed. This can happen for example when there is a
node with multiple muxes between crtc and encoder.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/drm_of.c | 4 ++--
include/drm/drm_of.h | 8 ++++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 1fe122461298..2e9cea3287b2 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
* Given a port OF node, return the possible mask of the corresponding
* CRTC within a device's list of CRTCs. Returns zero if not found.
*/
-static uint32_t drm_crtc_port_mask(struct drm_device *dev,
- struct device_node *port)
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
{
unsigned int index = 0;
struct drm_crtc *tmp;
diff --git a/include/drm/drm_of.h b/include/drm/drm_of.h
index b93c239afb60..a61fd77e46ba 100644
--- a/include/drm/drm_of.h
+++ b/include/drm/drm_of.h
@@ -17,6 +17,8 @@ struct drm_bridge;
struct device_node;
#ifdef CONFIG_OF
+uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port);
uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port);
void drm_of_component_match_add(struct device *master,
@@ -34,6 +36,12 @@ int drm_of_find_panel_or_bridge(const struct device_node *np,
struct drm_panel **panel,
struct drm_bridge **bridge);
#else
+static inline uint32_t drm_crtc_port_mask(struct drm_device *dev,
+ struct device_node *port)
+{
+ return 0;
+}
+
static inline uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
struct device_node *port)
{
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* Re: [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-13 7:36 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:36 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens, robh+dt, airlied, gustavo, maarten.lankhorst, seanpaul,
mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> Function is useful when drm_of_find_possible_crtcs() can't be used and
> custom parsing is needed. This can happen for example when there is a
> node with multiple muxes between crtc and encoder.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/drm_of.c | 4 ++--
> include/drm/drm_of.h | 8 ++++++++
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 1fe122461298..2e9cea3287b2 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
> * Given a port OF node, return the possible mask of the corresponding
> * CRTC within a device's list of CRTCs. Returns zero if not found.
> */
> -static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> - struct device_node *port)
> +uint32_t drm_crtc_port_mask(struct drm_device *dev,
> + struct device_node *port)
It should probably be exported too?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-13 7:36 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:36 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> Function is useful when drm_of_find_possible_crtcs() can't be used and
> custom parsing is needed. This can happen for example when there is a
> node with multiple muxes between crtc and encoder.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/drm_of.c | 4 ++--
> include/drm/drm_of.h | 8 ++++++++
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 1fe122461298..2e9cea3287b2 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
> * Given a port OF node, return the possible mask of the corresponding
> * CRTC within a device's list of CRTCs. Returns zero if not found.
> */
> -static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> - struct device_node *port)
> +uint32_t drm_crtc_port_mask(struct drm_device *dev,
> + struct device_node *port)
It should probably be exported too?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180613/60f38f14/attachment.sig>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-13 7:36 ` Maxime Ripard
0 siblings, 0 replies; 201+ messages in thread
From: Maxime Ripard @ 2018-06-13 7:36 UTC (permalink / raw)
To: Jernej Skrabec
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> Function is useful when drm_of_find_possible_crtcs() can't be used and
> custom parsing is needed. This can happen for example when there is a
> node with multiple muxes between crtc and encoder.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> ---
> drivers/gpu/drm/drm_of.c | 4 ++--
> include/drm/drm_of.h | 8 ++++++++
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 1fe122461298..2e9cea3287b2 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void *data)
> * Given a port OF node, return the possible mask of the corresponding
> * CRTC within a device's list of CRTCs. Returns zero if not found.
> */
> -static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> - struct device_node *port)
> +uint32_t drm_crtc_port_mask(struct drm_device *dev,
> + struct device_node *port)
It should probably be exported too?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] Re: [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
2018-06-13 7:36 ` Maxime Ripard
(?)
@ 2018-06-13 16:04 ` Jernej Škrabec
-1 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:04 UTC (permalink / raw)
To: linux-sunxi, maxime.ripard
Cc: wens, robh+dt, airlied, gustavo, maarten.lankhorst, seanpaul,
mark.rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk
Dne sreda, 13. junij 2018 ob 09:36:05 CEST je Maxime Ripard napisal(a):
> On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> > Function is useful when drm_of_find_possible_crtcs() can't be used and
> > custom parsing is needed. This can happen for example when there is a
> > node with multiple muxes between crtc and encoder.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/drm_of.c | 4 ++--
> > include/drm/drm_of.h | 8 ++++++++
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > index 1fe122461298..2e9cea3287b2 100644
> > --- a/drivers/gpu/drm/drm_of.c
> > +++ b/drivers/gpu/drm/drm_of.c
> > @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void
> > *data)>
> > * Given a port OF node, return the possible mask of the corresponding
> > * CRTC within a device's list of CRTCs. Returns zero if not found.
> > */
> >
> > -static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> > - struct device_node *port)
> > +uint32_t drm_crtc_port_mask(struct drm_device *dev,
> > + struct device_node *port)
>
> It should probably be exported too?
Yes, of course. It will be in next version.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] Re: [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-13 16:04 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:04 UTC (permalink / raw)
To: linux-arm-kernel
Dne sreda, 13. junij 2018 ob 09:36:05 CEST je Maxime Ripard napisal(a):
> On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> > Function is useful when drm_of_find_possible_crtcs() can't be used and
> > custom parsing is needed. This can happen for example when there is a
> > node with multiple muxes between crtc and encoder.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/gpu/drm/drm_of.c | 4 ++--
> > include/drm/drm_of.h | 8 ++++++++
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > index 1fe122461298..2e9cea3287b2 100644
> > --- a/drivers/gpu/drm/drm_of.c
> > +++ b/drivers/gpu/drm/drm_of.c
> > @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void
> > *data)>
> > * Given a port OF node, return the possible mask of the corresponding
> > * CRTC within a device's list of CRTCs. Returns zero if not found.
> > */
> >
> > -static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> > - struct device_node *port)
> > +uint32_t drm_crtc_port_mask(struct drm_device *dev,
> > + struct device_node *port)
>
> It should probably be exported too?
Yes, of course. It will be in next version.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: Re: [PATCH v2 24/27] drm: of: Export drm_crtc_port_mask()
@ 2018-06-13 16:04 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-13 16:04 UTC (permalink / raw)
To: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ
Cc: wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA
Dne sreda, 13. junij 2018 ob 09:36:05 CEST je Maxime Ripard napisal(a):
> On Tue, Jun 12, 2018 at 10:00:33PM +0200, Jernej Skrabec wrote:
> > Function is useful when drm_of_find_possible_crtcs() can't be used and
> > custom parsing is needed. This can happen for example when there is a
> > node with multiple muxes between crtc and encoder.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> > ---
> >
> > drivers/gpu/drm/drm_of.c | 4 ++--
> > include/drm/drm_of.h | 8 ++++++++
> > 2 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > index 1fe122461298..2e9cea3287b2 100644
> > --- a/drivers/gpu/drm/drm_of.c
> > +++ b/drivers/gpu/drm/drm_of.c
> > @@ -22,8 +22,8 @@ static void drm_release_of(struct device *dev, void
> > *data)>
> > * Given a port OF node, return the possible mask of the corresponding
> > * CRTC within a device's list of CRTCs. Returns zero if not found.
> > */
> >
> > -static uint32_t drm_crtc_port_mask(struct drm_device *dev,
> > - struct device_node *port)
> > +uint32_t drm_crtc_port_mask(struct drm_device *dev,
> > + struct device_node *port)
>
> It should probably be exported too?
Yes, of course. It will be in next version.
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* [PATCH v2 25/27] drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
drm_of_find_possible_crtcs() doesn't work when DW HDMI encoder is
connected to TCON (crtc) through mux in TCON TOP.
In that case TCON TOP HDMI mux input port has to be manually traversed
and checked if it matches any known crtc.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 46 ++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 9f40a44b456b..d443886e055b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -12,6 +12,7 @@
#include <drm/drm_crtc_helper.h>
#include "sun8i_dw_hdmi.h"
+#include "sun8i_tcon_top.h"
static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
@@ -41,6 +42,48 @@ sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
+static bool sun8i_dw_hdmi_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
+static u32 sun8i_dw_hdmi_find_possible_crtcs(struct drm_device *drm,
+ struct device_node *node)
+{
+ struct device_node *port, *ep, *remote, *remote_port;
+ u32 crtcs = 0;
+
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return 0;
+
+ ep = of_get_next_available_child(port, NULL);
+ if (!ep)
+ return 0;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ return 0;
+
+ if (sun8i_dw_hdmi_node_is_tcon_top(remote)) {
+ port = of_graph_get_port_by_id(remote, 4);
+ if (!port)
+ return 0;
+
+ for_each_child_of_node(port, ep) {
+ remote_port = of_graph_get_remote_port(ep);
+ if (remote_port) {
+ crtcs |= drm_crtc_port_mask(drm, remote_port);
+ of_node_put(remote_port);
+ }
+ }
+ } else {
+ crtcs = drm_of_find_possible_crtcs(drm, node);
+ }
+
+ return crtcs;
+}
+
static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -63,7 +106,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
- encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ encoder->possible_crtcs =
+ sun8i_dw_hdmi_find_possible_crtcs(drm, dev->of_node);
/*
* If we failed to find the CRTC(s) which this encoder is
* supposed to be connected to, it's because the CRTC has
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 25/27] drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
drm_of_find_possible_crtcs() doesn't work when DW HDMI encoder is
connected to TCON (crtc) through mux in TCON TOP.
In that case TCON TOP HDMI mux input port has to be manually traversed
and checked if it matches any known crtc.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 46 ++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 9f40a44b456b..d443886e055b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -12,6 +12,7 @@
#include <drm/drm_crtc_helper.h>
#include "sun8i_dw_hdmi.h"
+#include "sun8i_tcon_top.h"
static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
@@ -41,6 +42,48 @@ sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
+static bool sun8i_dw_hdmi_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
+static u32 sun8i_dw_hdmi_find_possible_crtcs(struct drm_device *drm,
+ struct device_node *node)
+{
+ struct device_node *port, *ep, *remote, *remote_port;
+ u32 crtcs = 0;
+
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return 0;
+
+ ep = of_get_next_available_child(port, NULL);
+ if (!ep)
+ return 0;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ return 0;
+
+ if (sun8i_dw_hdmi_node_is_tcon_top(remote)) {
+ port = of_graph_get_port_by_id(remote, 4);
+ if (!port)
+ return 0;
+
+ for_each_child_of_node(port, ep) {
+ remote_port = of_graph_get_remote_port(ep);
+ if (remote_port) {
+ crtcs |= drm_crtc_port_mask(drm, remote_port);
+ of_node_put(remote_port);
+ }
+ }
+ } else {
+ crtcs = drm_of_find_possible_crtcs(drm, node);
+ }
+
+ return crtcs;
+}
+
static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -63,7 +106,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
- encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ encoder->possible_crtcs =
+ sun8i_dw_hdmi_find_possible_crtcs(drm, dev->of_node);
/*
* If we failed to find the CRTC(s) which this encoder is
* supposed to be connected to, it's because the CRTC has
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 25/27] drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
drm_of_find_possible_crtcs() doesn't work when DW HDMI encoder is
connected to TCON (crtc) through mux in TCON TOP.
In that case TCON TOP HDMI mux input port has to be manually traversed
and checked if it matches any known crtc.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 46 ++++++++++++++++++++++++++-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 9f40a44b456b..d443886e055b 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -12,6 +12,7 @@
#include <drm/drm_crtc_helper.h>
#include "sun8i_dw_hdmi.h"
+#include "sun8i_tcon_top.h"
static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
@@ -41,6 +42,48 @@ sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
return MODE_OK;
}
+static bool sun8i_dw_hdmi_node_is_tcon_top(struct device_node *node)
+{
+ return !!of_match_node(sun8i_tcon_top_of_table, node);
+}
+
+static u32 sun8i_dw_hdmi_find_possible_crtcs(struct drm_device *drm,
+ struct device_node *node)
+{
+ struct device_node *port, *ep, *remote, *remote_port;
+ u32 crtcs = 0;
+
+ port = of_graph_get_port_by_id(node, 0);
+ if (!port)
+ return 0;
+
+ ep = of_get_next_available_child(port, NULL);
+ if (!ep)
+ return 0;
+
+ remote = of_graph_get_remote_port_parent(ep);
+ if (!remote)
+ return 0;
+
+ if (sun8i_dw_hdmi_node_is_tcon_top(remote)) {
+ port = of_graph_get_port_by_id(remote, 4);
+ if (!port)
+ return 0;
+
+ for_each_child_of_node(port, ep) {
+ remote_port = of_graph_get_remote_port(ep);
+ if (remote_port) {
+ crtcs |= drm_crtc_port_mask(drm, remote_port);
+ of_node_put(remote_port);
+ }
+ }
+ } else {
+ crtcs = drm_of_find_possible_crtcs(drm, node);
+ }
+
+ return crtcs;
+}
+
static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
void *data)
{
@@ -63,7 +106,8 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
hdmi->dev = &pdev->dev;
encoder = &hdmi->encoder;
- encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ encoder->possible_crtcs =
+ sun8i_dw_hdmi_find_possible_crtcs(drm, dev->of_node);
/*
* If we failed to find the CRTC(s) which this encoder is
* supposed to be connected to, it's because the CRTC has
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 26/27] ARM: dts: sun8i: r40: Add HDMI pipeline
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Add all entries needed for HDMI to function properly.
Since R40 has highly configurable pipeline, both mixers and both TCON
TVs are added. Board specific DT should then connect them together
trough TCON TOP muxers to best fit the purpose of the board.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 257 +++++++++++++++++++++++++++++++
1 file changed, 257 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..17171c82457e 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -42,8 +42,11 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/clock/sun8i-r40-ccu.h>
+#include <dt-bindings/clock/sun8i-tcon-top.h>
#include <dt-bindings/reset/sun8i-r40-ccu.h>
+#include <dt-bindings/reset/sun8i-de2.h>
/ {
#address-cells = <1>;
@@ -99,12 +102,76 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-r40-display-engine",
+ "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ display_clocks: clock@1000000 {
+ compatible = "allwinner,sun8i-r40-de2-clk",
+ "allwinner,sun8i-h3-de2-clk";
+ reg = <0x01000000 0x100000>;
+ clocks = <&ccu CLK_DE>,
+ <&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer@1100000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-0";
+ reg = <0x01100000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+ <&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ reg = <1>;
+ mixer0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ mixer1: mixer@1200000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-1";
+ reg = <0x01200000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+ <&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ reg = <1>;
+ mixer1_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer1_in_mixer1>;
+ };
+ };
+ };
+ };
+
nmi_intc: interrupt-controller@1c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
@@ -451,6 +518,151 @@
#size-cells = <0>;
};
+ tcon_top: tcon-top@1c70000 {
+ compatible = "allwinner,sun8i-r40-tcon-top";
+ reg = <0x01c70000 0x1000>;
+ clocks = <&ccu CLK_BUS_TCON_TOP>;
+ clock-names = "bus";
+ resets = <&ccu RST_BUS_TCON_TOP>;
+ reset-names = "rst";
+ #clock-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_top_mixer0_in: port@0 {
+ reg = <0>;
+
+ tcon_top_mixer0_in_mixer0: endpoint {
+ remote-endpoint = <&mixer0_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon_top_mixer0_out_tcon_lcd0: endpoint@0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer0_out_tcon_lcd1: endpoint@1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv0: endpoint@2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv1: endpoint@3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_mixer1_in: port@2 {
+ reg = <2>;
+
+ tcon_top_mixer1_in_mixer1: endpoint {
+ remote-endpoint = <&mixer1_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer1_out: port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ tcon_top_mixer1_out_tcon_lcd0: endpoint@0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer1_out_tcon_lcd1: endpoint@1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv0: endpoint@2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv1: endpoint@3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_hdmi_in: port@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ tcon_top_hdmi_in_tcon_tv0: endpoint@0 {
+ reg = <0>;
+ };
+
+ tcon_top_hdmi_in_tcon_tv1: endpoint@1 {
+ reg = <1>;
+ };
+ };
+
+ tcon_top_hdmi_out: port@5 {
+ reg = <5>;
+
+ tcon_top_hdmi_out_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in_tcon_top>;
+ };
+ };
+ };
+ };
+
+ tcon_tv0: lcd-controller@1c73000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c73000 0x1000>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV0>, <&ccu CLK_TCON_TV0>,
+ <&tcon_top 1>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV0>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv0_in: port@0 {
+ reg = <0>;
+ };
+
+ tcon_tv0_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ tcon_tv1: lcd-controller@1c74000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c74000 0x1000>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV1>, <&ccu CLK_TCON_TV1>,
+ <&tcon_top 2>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv1_in: port@0 {
+ reg = <0>;
+ };
+
+ tcon_tv1_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
@@ -461,6 +673,51 @@
#interrupt-cells = <3>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+
+ hdmi: hdmi@1ee0000 {
+ compatible = "allwinner,sun8i-r40-dw-hdmi",
+ "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee0000 0x10000>;
+ reg-io-width = <1>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HDMI0>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+
+ hdmi_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi_phy: hdmi-phy@1ef0000 {
+ compatible = "allwinner,sun8i-r40-hdmi-phy",
+ "allwinner,sun50i-a64-hdmi-phy";
+ reg = <0x01ef0000 0x10000>;
+ clocks = <&ccu CLK_BUS_HDMI1>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu 7>, <&ccu 16>;
+ clock-names = "bus", "mod", "pll-0", "pll-1";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
};
timer {
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 26/27] ARM: dts: sun8i: r40: Add HDMI pipeline
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Add all entries needed for HDMI to function properly.
Since R40 has highly configurable pipeline, both mixers and both TCON
TVs are added. Board specific DT should then connect them together
trough TCON TOP muxers to best fit the purpose of the board.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 257 +++++++++++++++++++++++++++++++
1 file changed, 257 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..17171c82457e 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -42,8 +42,11 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/clock/sun8i-r40-ccu.h>
+#include <dt-bindings/clock/sun8i-tcon-top.h>
#include <dt-bindings/reset/sun8i-r40-ccu.h>
+#include <dt-bindings/reset/sun8i-de2.h>
/ {
#address-cells = <1>;
@@ -99,12 +102,76 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-r40-display-engine",
+ "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ display_clocks: clock at 1000000 {
+ compatible = "allwinner,sun8i-r40-de2-clk",
+ "allwinner,sun8i-h3-de2-clk";
+ reg = <0x01000000 0x100000>;
+ clocks = <&ccu CLK_DE>,
+ <&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer at 1100000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-0";
+ reg = <0x01100000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+ <&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port at 1 {
+ reg = <1>;
+ mixer0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ mixer1: mixer at 1200000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-1";
+ reg = <0x01200000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+ <&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port at 1 {
+ reg = <1>;
+ mixer1_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer1_in_mixer1>;
+ };
+ };
+ };
+ };
+
nmi_intc: interrupt-controller at 1c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
@@ -451,6 +518,151 @@
#size-cells = <0>;
};
+ tcon_top: tcon-top at 1c70000 {
+ compatible = "allwinner,sun8i-r40-tcon-top";
+ reg = <0x01c70000 0x1000>;
+ clocks = <&ccu CLK_BUS_TCON_TOP>;
+ clock-names = "bus";
+ resets = <&ccu RST_BUS_TCON_TOP>;
+ reset-names = "rst";
+ #clock-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_top_mixer0_in: port at 0 {
+ reg = <0>;
+
+ tcon_top_mixer0_in_mixer0: endpoint {
+ remote-endpoint = <&mixer0_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer0_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon_top_mixer0_out_tcon_lcd0: endpoint at 0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer0_out_tcon_lcd1: endpoint at 1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv0: endpoint at 2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv1: endpoint at 3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_mixer1_in: port at 2 {
+ reg = <2>;
+
+ tcon_top_mixer1_in_mixer1: endpoint {
+ remote-endpoint = <&mixer1_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer1_out: port at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ tcon_top_mixer1_out_tcon_lcd0: endpoint at 0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer1_out_tcon_lcd1: endpoint at 1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv0: endpoint at 2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv1: endpoint at 3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_hdmi_in: port at 4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ tcon_top_hdmi_in_tcon_tv0: endpoint at 0 {
+ reg = <0>;
+ };
+
+ tcon_top_hdmi_in_tcon_tv1: endpoint at 1 {
+ reg = <1>;
+ };
+ };
+
+ tcon_top_hdmi_out: port at 5 {
+ reg = <5>;
+
+ tcon_top_hdmi_out_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in_tcon_top>;
+ };
+ };
+ };
+ };
+
+ tcon_tv0: lcd-controller at 1c73000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c73000 0x1000>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV0>, <&ccu CLK_TCON_TV0>,
+ <&tcon_top 1>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV0>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv0_in: port at 0 {
+ reg = <0>;
+ };
+
+ tcon_tv0_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ tcon_tv1: lcd-controller at 1c74000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c74000 0x1000>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV1>, <&ccu CLK_TCON_TV1>,
+ <&tcon_top 2>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv1_in: port at 0 {
+ reg = <0>;
+ };
+
+ tcon_tv1_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
gic: interrupt-controller at 1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
@@ -461,6 +673,51 @@
#interrupt-cells = <3>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+
+ hdmi: hdmi at 1ee0000 {
+ compatible = "allwinner,sun8i-r40-dw-hdmi",
+ "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee0000 0x10000>;
+ reg-io-width = <1>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HDMI0>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port at 0 {
+ reg = <0>;
+
+ hdmi_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port at 1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi_phy: hdmi-phy at 1ef0000 {
+ compatible = "allwinner,sun8i-r40-hdmi-phy",
+ "allwinner,sun50i-a64-hdmi-phy";
+ reg = <0x01ef0000 0x10000>;
+ clocks = <&ccu CLK_BUS_HDMI1>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu 7>, <&ccu 16>;
+ clock-names = "bus", "mod", "pll-0", "pll-1";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
};
timer {
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 26/27] ARM: dts: sun8i: r40: Add HDMI pipeline
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Add all entries needed for HDMI to function properly.
Since R40 has highly configurable pipeline, both mixers and both TCON
TVs are added. Board specific DT should then connect them together
trough TCON TOP muxers to best fit the purpose of the board.
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
arch/arm/boot/dts/sun8i-r40.dtsi | 257 +++++++++++++++++++++++++++++++
1 file changed, 257 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi
index 173dcc1652d2..17171c82457e 100644
--- a/arch/arm/boot/dts/sun8i-r40.dtsi
+++ b/arch/arm/boot/dts/sun8i-r40.dtsi
@@ -42,8 +42,11 @@
*/
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/clock/sun8i-r40-ccu.h>
+#include <dt-bindings/clock/sun8i-tcon-top.h>
#include <dt-bindings/reset/sun8i-r40-ccu.h>
+#include <dt-bindings/reset/sun8i-de2.h>
/ {
#address-cells = <1>;
@@ -99,12 +102,76 @@
};
};
+ de: display-engine {
+ compatible = "allwinner,sun8i-r40-display-engine",
+ "allwinner,sun8i-h3-display-engine";
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
+ status = "disabled";
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ display_clocks: clock@1000000 {
+ compatible = "allwinner,sun8i-r40-de2-clk",
+ "allwinner,sun8i-h3-de2-clk";
+ reg = <0x01000000 0x100000>;
+ clocks = <&ccu CLK_DE>,
+ <&ccu CLK_BUS_DE>;
+ clock-names = "mod",
+ "bus";
+ resets = <&ccu RST_BUS_DE>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ mixer0: mixer@1100000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-0";
+ reg = <0x01100000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER0>,
+ <&display_clocks CLK_MIXER0>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_MIXER0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer0_out: port@1 {
+ reg = <1>;
+ mixer0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_in_mixer0>;
+ };
+ };
+ };
+ };
+
+ mixer1: mixer@1200000 {
+ compatible = "allwinner,sun8i-r40-de2-mixer-1";
+ reg = <0x01200000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+ <&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ reg = <1>;
+ mixer1_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer1_in_mixer1>;
+ };
+ };
+ };
+ };
+
nmi_intc: interrupt-controller@1c00030 {
compatible = "allwinner,sun7i-a20-sc-nmi";
interrupt-controller;
@@ -451,6 +518,151 @@
#size-cells = <0>;
};
+ tcon_top: tcon-top@1c70000 {
+ compatible = "allwinner,sun8i-r40-tcon-top";
+ reg = <0x01c70000 0x1000>;
+ clocks = <&ccu CLK_BUS_TCON_TOP>;
+ clock-names = "bus";
+ resets = <&ccu RST_BUS_TCON_TOP>;
+ reset-names = "rst";
+ #clock-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_top_mixer0_in: port@0 {
+ reg = <0>;
+
+ tcon_top_mixer0_in_mixer0: endpoint {
+ remote-endpoint = <&mixer0_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer0_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon_top_mixer0_out_tcon_lcd0: endpoint@0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer0_out_tcon_lcd1: endpoint@1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv0: endpoint@2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer0_out_tcon_tv1: endpoint@3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_mixer1_in: port@2 {
+ reg = <2>;
+
+ tcon_top_mixer1_in_mixer1: endpoint {
+ remote-endpoint = <&mixer1_out_tcon_top>;
+ };
+ };
+
+ tcon_top_mixer1_out: port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ tcon_top_mixer1_out_tcon_lcd0: endpoint@0 {
+ reg = <0>;
+ };
+
+ tcon_top_mixer1_out_tcon_lcd1: endpoint@1 {
+ reg = <1>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv0: endpoint@2 {
+ reg = <2>;
+ };
+
+ tcon_top_mixer1_out_tcon_tv1: endpoint@3 {
+ reg = <3>;
+ };
+ };
+
+ tcon_top_hdmi_in: port@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ tcon_top_hdmi_in_tcon_tv0: endpoint@0 {
+ reg = <0>;
+ };
+
+ tcon_top_hdmi_in_tcon_tv1: endpoint@1 {
+ reg = <1>;
+ };
+ };
+
+ tcon_top_hdmi_out: port@5 {
+ reg = <5>;
+
+ tcon_top_hdmi_out_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in_tcon_top>;
+ };
+ };
+ };
+ };
+
+ tcon_tv0: lcd-controller@1c73000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c73000 0x1000>;
+ interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV0>, <&ccu CLK_TCON_TV0>,
+ <&tcon_top 1>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV0>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv0_in: port@0 {
+ reg = <0>;
+ };
+
+ tcon_tv0_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ tcon_tv1: lcd-controller@1c74000 {
+ compatible = "allwinner,sun8i-r40-tcon-tv";
+ reg = <0x01c74000 0x1000>;
+ interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON_TV1>, <&ccu CLK_TCON_TV1>,
+ <&tcon_top 2>;
+ clock-names = "ahb", "tcon-ch1", "tcon-top";
+ resets = <&ccu RST_BUS_TCON_TV1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon_tv1_in: port@0 {
+ reg = <0>;
+ };
+
+ tcon_tv1_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
@@ -461,6 +673,51 @@
#interrupt-cells = <3>;
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+
+ hdmi: hdmi@1ee0000 {
+ compatible = "allwinner,sun8i-r40-dw-hdmi",
+ "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee0000 0x10000>;
+ reg-io-width = <1>;
+ interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HDMI0>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu CLK_HDMI>;
+ clock-names = "iahb", "isfr", "tmds";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port@0 {
+ reg = <0>;
+
+ hdmi_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi_phy: hdmi-phy@1ef0000 {
+ compatible = "allwinner,sun8i-r40-hdmi-phy",
+ "allwinner,sun50i-a64-hdmi-phy";
+ reg = <0x01ef0000 0x10000>;
+ clocks = <&ccu CLK_BUS_HDMI1>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu 7>, <&ccu 16>;
+ clock-names = "bus", "mod", "pll-0", "pll-1";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
};
timer {
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* [PATCH v2 27/27] ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt
Cc: airlied, gustavo, maarten.lankhorst, seanpaul, mark.rutland,
dri-devel, devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Since HDMI can be considered as main output, most capable mixer is
connected to it (mixer0).
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..0ebc2f9a980e 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -93,6 +104,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -101,6 +116,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c0 {
status = "okay";
@@ -195,6 +220,26 @@
status = "okay";
};
+&tcon_top_hdmi_in_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_out_tcon_top>;
+};
+
+&tcon_top_mixer0_out_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_in_tcon_top>;
+};
+
+&tcon_tv0_in {
+ tcon_tv0_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_out_tcon_tv0>;
+ };
+};
+
+&tcon_tv0_out {
+ tcon_tv0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_in_tcon_tv0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 27/27] ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: linux-arm-kernel
Since HDMI can be considered as main output, most capable mixer is
connected to it (mixer0).
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..0ebc2f9a980e 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -93,6 +104,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -101,6 +116,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c0 {
status = "okay";
@@ -195,6 +220,26 @@
status = "okay";
};
+&tcon_top_hdmi_in_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_out_tcon_top>;
+};
+
+&tcon_top_mixer0_out_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_in_tcon_top>;
+};
+
+&tcon_tv0_in {
+ tcon_tv0_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_out_tcon_tv0>;
+ };
+};
+
+&tcon_tv0_out {
+ tcon_tv0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_in_tcon_tv0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread* [PATCH v2 27/27] ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
@ 2018-06-12 20:00 ` Jernej Skrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Skrabec @ 2018-06-12 20:00 UTC (permalink / raw)
To: maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ, wens-jdAy2FN1RRM,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: airlied-cv59FeDIM0c, gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, mark.rutland-5wv7dgnIgG8,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Since HDMI can be considered as main output, most capable mixer is
connected to it (mixer0).
Signed-off-by: Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
---
.../boot/dts/sun8i-r40-bananapi-m2-ultra.dts | 45 +++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
index 27d9ccd0ef2f..0ebc2f9a980e 100644
--- a/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
+++ b/arch/arm/boot/dts/sun8i-r40-bananapi-m2-ultra.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -93,6 +104,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
status = "okay";
};
@@ -101,6 +116,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c0 {
status = "okay";
@@ -195,6 +220,26 @@
status = "okay";
};
+&tcon_top_hdmi_in_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_out_tcon_top>;
+};
+
+&tcon_top_mixer0_out_tcon_tv0 {
+ remote-endpoint = <&tcon_tv0_in_tcon_top>;
+};
+
+&tcon_tv0_in {
+ tcon_tv0_in_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_mixer0_out_tcon_tv0>;
+ };
+};
+
+&tcon_tv0_out {
+ tcon_tv0_out_tcon_top: endpoint {
+ remote-endpoint = <&tcon_top_hdmi_in_tcon_tv0>;
+ };
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
2.17.1
^ permalink raw reply related [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 7:12 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-14 7:12 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, seanpaul, Mark Rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> This series adds support for R40 HDMI pipeline. It is a bit special
> than other already supported pipelines because it has additional unit
> called TCON TOP responsible for relationship configuration between
> mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> and TV TCONs, TV encoder clock settings and pin muxing between LCD
> and TV encoders.
>
> However, it seems that TCON TOP will become a norm, since newer
> Allwinner SoCs like H6 also have this unit.
>
> I tested different possible configurations:
> - mixer0 <> TCON-TV0 <> HDMI
> - mixer0 <> TCON-TV1 <> HDMI
> - mixer1 <> TCON-TV0 <> HDMI
> - mixer1 <> TCON-TV1 <> HDMI
>
> Please review.
>
> Best regards,
> Jernej
>
> Changes from v1:
> - Split DT bindings patch and updated description
> - Split HDMI PHY patch
> - Move header file from TCON TOP patch to dt bindings patch
> - Added Rob reviewed-by tag
> - Used clk_hw_register_gate() instead of custom gate registration code
> - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> new patches were added.
> - Droped mixer index quirk patch
> - Reworked TCON support for TCON TOP
> - Updated commit messages
>
> Jernej Skrabec (27):
> clk: sunxi-ng: r40: Add minimal rate for video PLLs
> clk: sunxi-ng: r40: Allow setting parent rate to display related
> clocks
> clk: sunxi-ng: r40: Export video PLLs
> dt-bindings: display: sunxi-drm: Add TCON TOP description
> drm/sun4i: Add TCON TOP driver
> drm/sun4i: Fix releasing node when enumerating enpoints
> drm/sun4i: Split out code for enumerating endpoints in output port
> drm/sun4i: Add support for traversing graph with TCON TOP
> drm/sun4i: Don't skip TCONs if they don't have channel 0
> dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> drm/sun4i: tcon: Add support for tcon-top gate
> drm/sun4i: tcon: Generalize engine search algorithm
> drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> drm/sun4i: Don't check for panel or bridge on TV TCONs
> drm/sun4i: Add support for R40 TV TCON
> dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> drm/sun4i: Add support for R40 mixers
> dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> drm/sun4i: Enable DW HDMI PHY clock
> drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> drm/sun4i: DW HDMI PHY: Add support for second PLL
> drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> driver
> drm/sun4i: Add support for A64 HDMI PHY
> drm: of: Export drm_crtc_port_mask()
> drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> ARM: dts: sun8i: r40: Add HDMI pipeline
> ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
Tested whole series on top of linux-next.
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 7:12 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-14 7:12 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> This series adds support for R40 HDMI pipeline. It is a bit special
> than other already supported pipelines because it has additional unit
> called TCON TOP responsible for relationship configuration between
> mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> and TV TCONs, TV encoder clock settings and pin muxing between LCD
> and TV encoders.
>
> However, it seems that TCON TOP will become a norm, since newer
> Allwinner SoCs like H6 also have this unit.
>
> I tested different possible configurations:
> - mixer0 <> TCON-TV0 <> HDMI
> - mixer0 <> TCON-TV1 <> HDMI
> - mixer1 <> TCON-TV0 <> HDMI
> - mixer1 <> TCON-TV1 <> HDMI
>
> Please review.
>
> Best regards,
> Jernej
>
> Changes from v1:
> - Split DT bindings patch and updated description
> - Split HDMI PHY patch
> - Move header file from TCON TOP patch to dt bindings patch
> - Added Rob reviewed-by tag
> - Used clk_hw_register_gate() instead of custom gate registration code
> - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> new patches were added.
> - Droped mixer index quirk patch
> - Reworked TCON support for TCON TOP
> - Updated commit messages
>
> Jernej Skrabec (27):
> clk: sunxi-ng: r40: Add minimal rate for video PLLs
> clk: sunxi-ng: r40: Allow setting parent rate to display related
> clocks
> clk: sunxi-ng: r40: Export video PLLs
> dt-bindings: display: sunxi-drm: Add TCON TOP description
> drm/sun4i: Add TCON TOP driver
> drm/sun4i: Fix releasing node when enumerating enpoints
> drm/sun4i: Split out code for enumerating endpoints in output port
> drm/sun4i: Add support for traversing graph with TCON TOP
> drm/sun4i: Don't skip TCONs if they don't have channel 0
> dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> drm/sun4i: tcon: Add support for tcon-top gate
> drm/sun4i: tcon: Generalize engine search algorithm
> drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> drm/sun4i: Don't check for panel or bridge on TV TCONs
> drm/sun4i: Add support for R40 TV TCON
> dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> drm/sun4i: Add support for R40 mixers
> dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> drm/sun4i: Enable DW HDMI PHY clock
> drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> drm/sun4i: DW HDMI PHY: Add support for second PLL
> drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> driver
> drm/sun4i: Add support for A64 HDMI PHY
> drm: of: Export drm_crtc_port_mask()
> drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> ARM: dts: sun8i: r40: Add HDMI pipeline
> ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
Tested whole series on top of linux-next.
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 7:12 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-14 7:12 UTC (permalink / raw)
To: Jernej Skrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> This series adds support for R40 HDMI pipeline. It is a bit special
> than other already supported pipelines because it has additional unit
> called TCON TOP responsible for relationship configuration between
> mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> and TV TCONs, TV encoder clock settings and pin muxing between LCD
> and TV encoders.
>
> However, it seems that TCON TOP will become a norm, since newer
> Allwinner SoCs like H6 also have this unit.
>
> I tested different possible configurations:
> - mixer0 <> TCON-TV0 <> HDMI
> - mixer0 <> TCON-TV1 <> HDMI
> - mixer1 <> TCON-TV0 <> HDMI
> - mixer1 <> TCON-TV1 <> HDMI
>
> Please review.
>
> Best regards,
> Jernej
>
> Changes from v1:
> - Split DT bindings patch and updated description
> - Split HDMI PHY patch
> - Move header file from TCON TOP patch to dt bindings patch
> - Added Rob reviewed-by tag
> - Used clk_hw_register_gate() instead of custom gate registration code
> - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> new patches were added.
> - Droped mixer index quirk patch
> - Reworked TCON support for TCON TOP
> - Updated commit messages
>
> Jernej Skrabec (27):
> clk: sunxi-ng: r40: Add minimal rate for video PLLs
> clk: sunxi-ng: r40: Allow setting parent rate to display related
> clocks
> clk: sunxi-ng: r40: Export video PLLs
> dt-bindings: display: sunxi-drm: Add TCON TOP description
> drm/sun4i: Add TCON TOP driver
> drm/sun4i: Fix releasing node when enumerating enpoints
> drm/sun4i: Split out code for enumerating endpoints in output port
> drm/sun4i: Add support for traversing graph with TCON TOP
> drm/sun4i: Don't skip TCONs if they don't have channel 0
> dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> drm/sun4i: tcon: Add support for tcon-top gate
> drm/sun4i: tcon: Generalize engine search algorithm
> drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> drm/sun4i: Don't check for panel or bridge on TV TCONs
> drm/sun4i: Add support for R40 TV TCON
> dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> drm/sun4i: Add support for R40 mixers
> dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> drm/sun4i: Enable DW HDMI PHY clock
> drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> drm/sun4i: DW HDMI PHY: Add support for second PLL
> drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> driver
> drm/sun4i: Add support for A64 HDMI PHY
> drm: of: Export drm_crtc_port_mask()
> drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> ARM: dts: sun8i: r40: Add HDMI pipeline
> ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
Tested whole series on top of linux-next.
Tested-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 14:34 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-14 14:34 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, seanpaul, Mark Rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
wrote:
> > This series adds support for R40 HDMI pipeline. It is a bit special
> > than other already supported pipelines because it has additional unit
> > called TCON TOP responsible for relationship configuration between
> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> > and TV encoders.
> >
> > However, it seems that TCON TOP will become a norm, since newer
> > Allwinner SoCs like H6 also have this unit.
> >
> > I tested different possible configurations:
> > - mixer0 <> TCON-TV0 <> HDMI
> > - mixer0 <> TCON-TV1 <> HDMI
> > - mixer1 <> TCON-TV0 <> HDMI
> > - mixer1 <> TCON-TV1 <> HDMI
> >
> > Please review.
> >
> > Best regards,
> > Jernej
> >
> > Changes from v1:
> > - Split DT bindings patch and updated description
> > - Split HDMI PHY patch
> > - Move header file from TCON TOP patch to dt bindings patch
> > - Added Rob reviewed-by tag
> > - Used clk_hw_register_gate() instead of custom gate registration code
> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> >
> > new patches were added.
> >
> > - Droped mixer index quirk patch
> > - Reworked TCON support for TCON TOP
> > - Updated commit messages
> >
> > Jernej Skrabec (27):
> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >
> > clocks
> >
> > clk: sunxi-ng: r40: Export video PLLs
> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> > drm/sun4i: Add TCON TOP driver
> > drm/sun4i: Fix releasing node when enumerating enpoints
> > drm/sun4i: Split out code for enumerating endpoints in output port
> > drm/sun4i: Add support for traversing graph with TCON TOP
> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> > drm/sun4i: tcon: Add support for tcon-top gate
> > drm/sun4i: tcon: Generalize engine search algorithm
> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > drm/sun4i: Add support for R40 TV TCON
> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> > drm/sun4i: Add support for R40 mixers
> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> > drm/sun4i: Enable DW HDMI PHY clock
> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >
> > driver
> >
> > drm/sun4i: Add support for A64 HDMI PHY
> > drm: of: Export drm_crtc_port_mask()
> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > ARM: dts: sun8i: r40: Add HDMI pipeline
> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>
> Tested whole series on top of linux-next.
>
> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Thanks!
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 14:34 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-14 14:34 UTC (permalink / raw)
To: linux-arm-kernel
Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
wrote:
> > This series adds support for R40 HDMI pipeline. It is a bit special
> > than other already supported pipelines because it has additional unit
> > called TCON TOP responsible for relationship configuration between
> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> > and TV encoders.
> >
> > However, it seems that TCON TOP will become a norm, since newer
> > Allwinner SoCs like H6 also have this unit.
> >
> > I tested different possible configurations:
> > - mixer0 <> TCON-TV0 <> HDMI
> > - mixer0 <> TCON-TV1 <> HDMI
> > - mixer1 <> TCON-TV0 <> HDMI
> > - mixer1 <> TCON-TV1 <> HDMI
> >
> > Please review.
> >
> > Best regards,
> > Jernej
> >
> > Changes from v1:
> > - Split DT bindings patch and updated description
> > - Split HDMI PHY patch
> > - Move header file from TCON TOP patch to dt bindings patch
> > - Added Rob reviewed-by tag
> > - Used clk_hw_register_gate() instead of custom gate registration code
> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> >
> > new patches were added.
> >
> > - Droped mixer index quirk patch
> > - Reworked TCON support for TCON TOP
> > - Updated commit messages
> >
> > Jernej Skrabec (27):
> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >
> > clocks
> >
> > clk: sunxi-ng: r40: Export video PLLs
> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> > drm/sun4i: Add TCON TOP driver
> > drm/sun4i: Fix releasing node when enumerating enpoints
> > drm/sun4i: Split out code for enumerating endpoints in output port
> > drm/sun4i: Add support for traversing graph with TCON TOP
> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> > drm/sun4i: tcon: Add support for tcon-top gate
> > drm/sun4i: tcon: Generalize engine search algorithm
> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > drm/sun4i: Add support for R40 TV TCON
> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> > drm/sun4i: Add support for R40 mixers
> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> > drm/sun4i: Enable DW HDMI PHY clock
> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >
> > driver
> >
> > drm/sun4i: Add support for A64 HDMI PHY
> > drm: of: Export drm_crtc_port_mask()
> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > ARM: dts: sun8i: r40: Add HDMI pipeline
> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>
> Tested whole series on top of linux-next.
>
> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Thanks!
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 14:34 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-14 14:34 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
wrote:
> > This series adds support for R40 HDMI pipeline. It is a bit special
> > than other already supported pipelines because it has additional unit
> > called TCON TOP responsible for relationship configuration between
> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> > and TV encoders.
> >
> > However, it seems that TCON TOP will become a norm, since newer
> > Allwinner SoCs like H6 also have this unit.
> >
> > I tested different possible configurations:
> > - mixer0 <> TCON-TV0 <> HDMI
> > - mixer0 <> TCON-TV1 <> HDMI
> > - mixer1 <> TCON-TV0 <> HDMI
> > - mixer1 <> TCON-TV1 <> HDMI
> >
> > Please review.
> >
> > Best regards,
> > Jernej
> >
> > Changes from v1:
> > - Split DT bindings patch and updated description
> > - Split HDMI PHY patch
> > - Move header file from TCON TOP patch to dt bindings patch
> > - Added Rob reviewed-by tag
> > - Used clk_hw_register_gate() instead of custom gate registration code
> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> >
> > new patches were added.
> >
> > - Droped mixer index quirk patch
> > - Reworked TCON support for TCON TOP
> > - Updated commit messages
> >
> > Jernej Skrabec (27):
> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >
> > clocks
> >
> > clk: sunxi-ng: r40: Export video PLLs
> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> > drm/sun4i: Add TCON TOP driver
> > drm/sun4i: Fix releasing node when enumerating enpoints
> > drm/sun4i: Split out code for enumerating endpoints in output port
> > drm/sun4i: Add support for traversing graph with TCON TOP
> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> > drm/sun4i: tcon: Add support for tcon-top gate
> > drm/sun4i: tcon: Generalize engine search algorithm
> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > drm/sun4i: Add support for R40 TV TCON
> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> > drm/sun4i: Add support for R40 mixers
> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> > drm/sun4i: Enable DW HDMI PHY clock
> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >
> > driver
> >
> > drm/sun4i: Add support for A64 HDMI PHY
> > drm: of: Export drm_crtc_port_mask()
> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > ARM: dts: sun8i: r40: Add HDMI pipeline
> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>
> Tested whole series on top of linux-next.
>
> Tested-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Thanks!
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
2018-06-14 14:34 ` Jernej Škrabec
(?)
(?)
@ 2018-06-14 17:16 ` Jagan Teki
-1 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-14 17:16 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, seanpaul, Mark Rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
>> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> wrote:
>> > This series adds support for R40 HDMI pipeline. It is a bit special
>> > than other already supported pipelines because it has additional unit
>> > called TCON TOP responsible for relationship configuration between
>> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
>> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> > and TV encoders.
>> >
>> > However, it seems that TCON TOP will become a norm, since newer
>> > Allwinner SoCs like H6 also have this unit.
>> >
>> > I tested different possible configurations:
>> > - mixer0 <> TCON-TV0 <> HDMI
>> > - mixer0 <> TCON-TV1 <> HDMI
>> > - mixer1 <> TCON-TV0 <> HDMI
>> > - mixer1 <> TCON-TV1 <> HDMI
>> >
>> > Please review.
>> >
>> > Best regards,
>> > Jernej
>> >
>> > Changes from v1:
>> > - Split DT bindings patch and updated description
>> > - Split HDMI PHY patch
>> > - Move header file from TCON TOP patch to dt bindings patch
>> > - Added Rob reviewed-by tag
>> > - Used clk_hw_register_gate() instead of custom gate registration code
>> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
>> >
>> > new patches were added.
>> >
>> > - Droped mixer index quirk patch
>> > - Reworked TCON support for TCON TOP
>> > - Updated commit messages
>> >
>> > Jernej Skrabec (27):
>> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >
>> > clocks
>> >
>> > clk: sunxi-ng: r40: Export video PLLs
>> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> > drm/sun4i: Add TCON TOP driver
>> > drm/sun4i: Fix releasing node when enumerating enpoints
>> > drm/sun4i: Split out code for enumerating endpoints in output port
>> > drm/sun4i: Add support for traversing graph with TCON TOP
>> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> > drm/sun4i: tcon: Add support for tcon-top gate
>> > drm/sun4i: tcon: Generalize engine search algorithm
>> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> > drm/sun4i: Add support for R40 TV TCON
>> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> > drm/sun4i: Add support for R40 mixers
>> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> > drm/sun4i: Enable DW HDMI PHY clock
>> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >
>> > driver
>> >
>> > drm/sun4i: Add support for A64 HDMI PHY
>> > drm: of: Export drm_crtc_port_mask()
>> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>>
>> Tested whole series on top of linux-next.
>>
>> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Thanks!
I've V40 board, which is same as R40. I'm able to detect the HDMI but
seems edid not detecting properly.
[ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops 0xc074a80c)
[ 0.999043] sun4i-drm display-engine: bound 1200000.mixer (ops 0xc074a80c)
[ 1.006229] sun4i-drm display-engine: bound 1c70000.tcon-top (ops 0xc074e2ac)
[ 1.013609] sun4i-drm display-engine: bound 1c73000.lcd-controller
(ops 0xc0747a28)
[ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
v1.32a with HDCP (sun8i_dw_hdmi_phy)
[ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
I2C bus driver
[ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
[ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1.085098] [drm] No driver support for vblank timestamp query.
[ 1.091055] [drm] Cannot find any crtc or sizes
[ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
display-engine on minor 0
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 17:16 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-14 17:16 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec@siol.net> wrote:
> Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
>> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> wrote:
>> > This series adds support for R40 HDMI pipeline. It is a bit special
>> > than other already supported pipelines because it has additional unit
>> > called TCON TOP responsible for relationship configuration between
>> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
>> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> > and TV encoders.
>> >
>> > However, it seems that TCON TOP will become a norm, since newer
>> > Allwinner SoCs like H6 also have this unit.
>> >
>> > I tested different possible configurations:
>> > - mixer0 <> TCON-TV0 <> HDMI
>> > - mixer0 <> TCON-TV1 <> HDMI
>> > - mixer1 <> TCON-TV0 <> HDMI
>> > - mixer1 <> TCON-TV1 <> HDMI
>> >
>> > Please review.
>> >
>> > Best regards,
>> > Jernej
>> >
>> > Changes from v1:
>> > - Split DT bindings patch and updated description
>> > - Split HDMI PHY patch
>> > - Move header file from TCON TOP patch to dt bindings patch
>> > - Added Rob reviewed-by tag
>> > - Used clk_hw_register_gate() instead of custom gate registration code
>> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
>> >
>> > new patches were added.
>> >
>> > - Droped mixer index quirk patch
>> > - Reworked TCON support for TCON TOP
>> > - Updated commit messages
>> >
>> > Jernej Skrabec (27):
>> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >
>> > clocks
>> >
>> > clk: sunxi-ng: r40: Export video PLLs
>> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> > drm/sun4i: Add TCON TOP driver
>> > drm/sun4i: Fix releasing node when enumerating enpoints
>> > drm/sun4i: Split out code for enumerating endpoints in output port
>> > drm/sun4i: Add support for traversing graph with TCON TOP
>> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> > drm/sun4i: tcon: Add support for tcon-top gate
>> > drm/sun4i: tcon: Generalize engine search algorithm
>> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> > drm/sun4i: Add support for R40 TV TCON
>> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> > drm/sun4i: Add support for R40 mixers
>> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> > drm/sun4i: Enable DW HDMI PHY clock
>> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >
>> > driver
>> >
>> > drm/sun4i: Add support for A64 HDMI PHY
>> > drm: of: Export drm_crtc_port_mask()
>> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>>
>> Tested whole series on top of linux-next.
>>
>> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Thanks!
I've V40 board, which is same as R40. I'm able to detect the HDMI but
seems edid not detecting properly.
[ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops 0xc074a80c)
[ 0.999043] sun4i-drm display-engine: bound 1200000.mixer (ops 0xc074a80c)
[ 1.006229] sun4i-drm display-engine: bound 1c70000.tcon-top (ops 0xc074e2ac)
[ 1.013609] sun4i-drm display-engine: bound 1c73000.lcd-controller
(ops 0xc0747a28)
[ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
v1.32a with HDCP (sun8i_dw_hdmi_phy)
[ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
I2C bus driver
[ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
[ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1.085098] [drm] No driver support for vblank timestamp query.
[ 1.091055] [drm] Cannot find any crtc or sizes
[ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
display-engine on minor 0
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 17:16 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-14 17:16 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, seanpaul, Mark Rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
On Thu, Jun 14, 2018 at 8:04 PM, Jernej =C5=A0krabec <jernej.skrabec@siol.n=
et> wrote:
> Dne =C4=8Detrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a=
):
>> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net=
>
> wrote:
>> > This series adds support for R40 HDMI pipeline. It is a bit special
>> > than other already supported pipelines because it has additional unit
>> > called TCON TOP responsible for relationship configuration between
>> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
>> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> > and TV encoders.
>> >
>> > However, it seems that TCON TOP will become a norm, since newer
>> > Allwinner SoCs like H6 also have this unit.
>> >
>> > I tested different possible configurations:
>> > - mixer0 <> TCON-TV0 <> HDMI
>> > - mixer0 <> TCON-TV1 <> HDMI
>> > - mixer1 <> TCON-TV0 <> HDMI
>> > - mixer1 <> TCON-TV1 <> HDMI
>> >
>> > Please review.
>> >
>> > Best regards,
>> > Jernej
>> >
>> > Changes from v1:
>> > - Split DT bindings patch and updated description
>> > - Split HDMI PHY patch
>> > - Move header file from TCON TOP patch to dt bindings patch
>> > - Added Rob reviewed-by tag
>> > - Used clk_hw_register_gate() instead of custom gate registration code
>> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
>> >
>> > new patches were added.
>> >
>> > - Droped mixer index quirk patch
>> > - Reworked TCON support for TCON TOP
>> > - Updated commit messages
>> >
>> > Jernej Skrabec (27):
>> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >
>> > clocks
>> >
>> > clk: sunxi-ng: r40: Export video PLLs
>> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> > drm/sun4i: Add TCON TOP driver
>> > drm/sun4i: Fix releasing node when enumerating enpoints
>> > drm/sun4i: Split out code for enumerating endpoints in output port
>> > drm/sun4i: Add support for traversing graph with TCON TOP
>> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> > drm/sun4i: tcon: Add support for tcon-top gate
>> > drm/sun4i: tcon: Generalize engine search algorithm
>> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> > drm/sun4i: Add support for R40 TV TCON
>> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> > drm/sun4i: Add support for R40 mixers
>> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> > drm/sun4i: Enable DW HDMI PHY clock
>> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >
>> > driver
>> >
>> > drm/sun4i: Add support for A64 HDMI PHY
>> > drm: of: Export drm_crtc_port_mask()
>> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>>
>> Tested whole series on top of linux-next.
>>
>> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Thanks!
I've V40 board, which is same as R40. I'm able to detect the HDMI but
seems edid not detecting properly.
[ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops 0xc074a80=
c)
[ 0.999043] sun4i-drm display-engine: bound 1200000.mixer (ops 0xc074a80=
c)
[ 1.006229] sun4i-drm display-engine: bound 1c70000.tcon-top (ops 0xc074=
e2ac)
[ 1.013609] sun4i-drm display-engine: bound 1c73000.lcd-controller
(ops 0xc0747a28)
[ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
v1.32a with HDCP (sun8i_dw_hdmi_phy)
[ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
I2C bus driver
[ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298=
)
[ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1.085098] [drm] No driver support for vblank timestamp query.
[ 1.091055] [drm] Cannot find any crtc or sizes
[ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
display-engine on minor 0
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 17:16 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-14 17:16 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net> wrote:
> Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
>> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> wrote:
>> > This series adds support for R40 HDMI pipeline. It is a bit special
>> > than other already supported pipelines because it has additional unit
>> > called TCON TOP responsible for relationship configuration between
>> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
>> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> > and TV encoders.
>> >
>> > However, it seems that TCON TOP will become a norm, since newer
>> > Allwinner SoCs like H6 also have this unit.
>> >
>> > I tested different possible configurations:
>> > - mixer0 <> TCON-TV0 <> HDMI
>> > - mixer0 <> TCON-TV1 <> HDMI
>> > - mixer1 <> TCON-TV0 <> HDMI
>> > - mixer1 <> TCON-TV1 <> HDMI
>> >
>> > Please review.
>> >
>> > Best regards,
>> > Jernej
>> >
>> > Changes from v1:
>> > - Split DT bindings patch and updated description
>> > - Split HDMI PHY patch
>> > - Move header file from TCON TOP patch to dt bindings patch
>> > - Added Rob reviewed-by tag
>> > - Used clk_hw_register_gate() instead of custom gate registration code
>> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
>> >
>> > new patches were added.
>> >
>> > - Droped mixer index quirk patch
>> > - Reworked TCON support for TCON TOP
>> > - Updated commit messages
>> >
>> > Jernej Skrabec (27):
>> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >
>> > clocks
>> >
>> > clk: sunxi-ng: r40: Export video PLLs
>> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> > drm/sun4i: Add TCON TOP driver
>> > drm/sun4i: Fix releasing node when enumerating enpoints
>> > drm/sun4i: Split out code for enumerating endpoints in output port
>> > drm/sun4i: Add support for traversing graph with TCON TOP
>> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> > drm/sun4i: tcon: Add support for tcon-top gate
>> > drm/sun4i: tcon: Generalize engine search algorithm
>> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> > drm/sun4i: Add support for R40 TV TCON
>> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> > drm/sun4i: Add support for R40 mixers
>> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> > drm/sun4i: Enable DW HDMI PHY clock
>> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >
>> > driver
>> >
>> > drm/sun4i: Add support for A64 HDMI PHY
>> > drm: of: Export drm_crtc_port_mask()
>> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>>
>> Tested whole series on top of linux-next.
>>
>> Tested-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>
> Thanks!
I've V40 board, which is same as R40. I'm able to detect the HDMI but
seems edid not detecting properly.
[ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops 0xc074a80c)
[ 0.999043] sun4i-drm display-engine: bound 1200000.mixer (ops 0xc074a80c)
[ 1.006229] sun4i-drm display-engine: bound 1c70000.tcon-top (ops 0xc074e2ac)
[ 1.013609] sun4i-drm display-engine: bound 1c73000.lcd-controller
(ops 0xc0747a28)
[ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
v1.32a with HDCP (sun8i_dw_hdmi_phy)
[ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
I2C bus driver
[ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
[ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1.085098] [drm] No driver support for vblank timestamp query.
[ 1.091055] [drm] Cannot find any crtc or sizes
[ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
display-engine on minor 0
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 17:29 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-14 17:29 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, seanpaul, Mark Rutland, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, linux-clk, linux-sunxi
Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net>
wrote:
> > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > This series adds support for R40 HDMI pipeline. It is a bit special
> >> > than other already supported pipelines because it has additional unit
> >> > called TCON TOP responsible for relationship configuration between
> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> >> > and TV encoders.
> >> >
> >> > However, it seems that TCON TOP will become a norm, since newer
> >> > Allwinner SoCs like H6 also have this unit.
> >> >
> >> > I tested different possible configurations:
> >> > - mixer0 <> TCON-TV0 <> HDMI
> >> > - mixer0 <> TCON-TV1 <> HDMI
> >> > - mixer1 <> TCON-TV0 <> HDMI
> >> > - mixer1 <> TCON-TV1 <> HDMI
> >> >
> >> > Please review.
> >> >
> >> > Best regards,
> >> > Jernej
> >> >
> >> > Changes from v1:
> >> > - Split DT bindings patch and updated description
> >> > - Split HDMI PHY patch
> >> > - Move header file from TCON TOP patch to dt bindings patch
> >> > - Added Rob reviewed-by tag
> >> > - Used clk_hw_register_gate() instead of custom gate registration code
> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> >> >
> >> > new patches were added.
> >> >
> >> > - Droped mixer index quirk patch
> >> > - Reworked TCON support for TCON TOP
> >> > - Updated commit messages
> >> >
> >> > Jernej Skrabec (27):
> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >> >
> >> > clocks
> >> >
> >> > clk: sunxi-ng: r40: Export video PLLs
> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> >> > drm/sun4i: Add TCON TOP driver
> >> > drm/sun4i: Fix releasing node when enumerating enpoints
> >> > drm/sun4i: Split out code for enumerating endpoints in output port
> >> > drm/sun4i: Add support for traversing graph with TCON TOP
> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> >> > drm/sun4i: tcon: Add support for tcon-top gate
> >> > drm/sun4i: tcon: Generalize engine search algorithm
> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> >> > drm/sun4i: Add support for R40 TV TCON
> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> >> > drm/sun4i: Add support for R40 mixers
> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> >> > drm/sun4i: Enable DW HDMI PHY clock
> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >> >
> >> > driver
> >> >
> >> > drm/sun4i: Add support for A64 HDMI PHY
> >> > drm: of: Export drm_crtc_port_mask()
> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
> >>
> >> Tested whole series on top of linux-next.
> >>
> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> >
> > Thanks!
>
> I've V40 board, which is same as R40. I'm able to detect the HDMI but
> seems edid not detecting properly.
>
> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm display-engine:
> bound 1c73000.lcd-controller (ops 0xc0747a28)
> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
> v1.32a with HDCP (sun8i_dw_hdmi_phy)
> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
> I2C bus driver
> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
> [ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 1.085098] [drm] No driver support for vblank timestamp query. [
> 1.091055] [drm] Cannot find any crtc or sizes
> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> display-engine on minor 0
This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
different to R40) and board DTS?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 17:29 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-14 17:29 UTC (permalink / raw)
To: linux-arm-kernel
Dne ?etrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec@siol.net>
wrote:
> > Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > This series adds support for R40 HDMI pipeline. It is a bit special
> >> > than other already supported pipelines because it has additional unit
> >> > called TCON TOP responsible for relationship configuration between
> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> >> > and TV encoders.
> >> >
> >> > However, it seems that TCON TOP will become a norm, since newer
> >> > Allwinner SoCs like H6 also have this unit.
> >> >
> >> > I tested different possible configurations:
> >> > - mixer0 <> TCON-TV0 <> HDMI
> >> > - mixer0 <> TCON-TV1 <> HDMI
> >> > - mixer1 <> TCON-TV0 <> HDMI
> >> > - mixer1 <> TCON-TV1 <> HDMI
> >> >
> >> > Please review.
> >> >
> >> > Best regards,
> >> > Jernej
> >> >
> >> > Changes from v1:
> >> > - Split DT bindings patch and updated description
> >> > - Split HDMI PHY patch
> >> > - Move header file from TCON TOP patch to dt bindings patch
> >> > - Added Rob reviewed-by tag
> >> > - Used clk_hw_register_gate() instead of custom gate registration code
> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> >> >
> >> > new patches were added.
> >> >
> >> > - Droped mixer index quirk patch
> >> > - Reworked TCON support for TCON TOP
> >> > - Updated commit messages
> >> >
> >> > Jernej Skrabec (27):
> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >> >
> >> > clocks
> >> >
> >> > clk: sunxi-ng: r40: Export video PLLs
> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> >> > drm/sun4i: Add TCON TOP driver
> >> > drm/sun4i: Fix releasing node when enumerating enpoints
> >> > drm/sun4i: Split out code for enumerating endpoints in output port
> >> > drm/sun4i: Add support for traversing graph with TCON TOP
> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> >> > drm/sun4i: tcon: Add support for tcon-top gate
> >> > drm/sun4i: tcon: Generalize engine search algorithm
> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> >> > drm/sun4i: Add support for R40 TV TCON
> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> >> > drm/sun4i: Add support for R40 mixers
> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> >> > drm/sun4i: Enable DW HDMI PHY clock
> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >> >
> >> > driver
> >> >
> >> > drm/sun4i: Add support for A64 HDMI PHY
> >> > drm: of: Export drm_crtc_port_mask()
> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
> >>
> >> Tested whole series on top of linux-next.
> >>
> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> >
> > Thanks!
>
> I've V40 board, which is same as R40. I'm able to detect the HDMI but
> seems edid not detecting properly.
>
> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm display-engine:
> bound 1c73000.lcd-controller (ops 0xc0747a28)
> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
> v1.32a with HDCP (sun8i_dw_hdmi_phy)
> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
> I2C bus driver
> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
> [ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 1.085098] [drm] No driver support for vblank timestamp query. [
> 1.091055] [drm] Cannot find any crtc or sizes
> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> display-engine on minor 0
This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
different to R40) and board DTS?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-14 17:29 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-14 17:29 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net>
wrote:
> > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > This series adds support for R40 HDMI pipeline. It is a bit special
> >> > than other already supported pipelines because it has additional unit
> >> > called TCON TOP responsible for relationship configuration between
> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> >> > and TV encoders.
> >> >
> >> > However, it seems that TCON TOP will become a norm, since newer
> >> > Allwinner SoCs like H6 also have this unit.
> >> >
> >> > I tested different possible configurations:
> >> > - mixer0 <> TCON-TV0 <> HDMI
> >> > - mixer0 <> TCON-TV1 <> HDMI
> >> > - mixer1 <> TCON-TV0 <> HDMI
> >> > - mixer1 <> TCON-TV1 <> HDMI
> >> >
> >> > Please review.
> >> >
> >> > Best regards,
> >> > Jernej
> >> >
> >> > Changes from v1:
> >> > - Split DT bindings patch and updated description
> >> > - Split HDMI PHY patch
> >> > - Move header file from TCON TOP patch to dt bindings patch
> >> > - Added Rob reviewed-by tag
> >> > - Used clk_hw_register_gate() instead of custom gate registration code
> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
> >> >
> >> > new patches were added.
> >> >
> >> > - Droped mixer index quirk patch
> >> > - Reworked TCON support for TCON TOP
> >> > - Updated commit messages
> >> >
> >> > Jernej Skrabec (27):
> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >> >
> >> > clocks
> >> >
> >> > clk: sunxi-ng: r40: Export video PLLs
> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> >> > drm/sun4i: Add TCON TOP driver
> >> > drm/sun4i: Fix releasing node when enumerating enpoints
> >> > drm/sun4i: Split out code for enumerating endpoints in output port
> >> > drm/sun4i: Add support for traversing graph with TCON TOP
> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> >> > drm/sun4i: tcon: Add support for tcon-top gate
> >> > drm/sun4i: tcon: Generalize engine search algorithm
> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> >> > drm/sun4i: Add support for R40 TV TCON
> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> >> > drm/sun4i: Add support for R40 mixers
> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> >> > drm/sun4i: Enable DW HDMI PHY clock
> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >> >
> >> > driver
> >> >
> >> > drm/sun4i: Add support for A64 HDMI PHY
> >> > drm: of: Export drm_crtc_port_mask()
> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
> >>
> >> Tested whole series on top of linux-next.
> >>
> >> Tested-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> >
> > Thanks!
>
> I've V40 board, which is same as R40. I'm able to detect the HDMI but
> seems edid not detecting properly.
>
> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm display-engine:
> bound 1c73000.lcd-controller (ops 0xc0747a28)
> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
> v1.32a with HDCP (sun8i_dw_hdmi_phy)
> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
> I2C bus driver
> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
> [ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [ 1.085098] [drm] No driver support for vblank timestamp query. [
> 1.091055] [drm] Cannot find any crtc or sizes
> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> display-engine on minor 0
This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
different to R40) and board DTS?
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
2018-06-14 17:29 ` Jernej Škrabec
(?)
(?)
@ 2018-06-18 12:58 ` Jagan Teki
-1 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-18 12:58 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Thu, Jun 14, 2018 at 10:59 PM, Jernej Škrabec
<jernej.skrabec@siol.net> wrote:
> Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
>> On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net>
> wrote:
>> > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
>> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
>> >
>> > wrote:
>> >> > This series adds support for R40 HDMI pipeline. It is a bit special
>> >> > than other already supported pipelines because it has additional unit
>> >> > called TCON TOP responsible for relationship configuration between
>> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
>> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> >> > and TV encoders.
>> >> >
>> >> > However, it seems that TCON TOP will become a norm, since newer
>> >> > Allwinner SoCs like H6 also have this unit.
>> >> >
>> >> > I tested different possible configurations:
>> >> > - mixer0 <> TCON-TV0 <> HDMI
>> >> > - mixer0 <> TCON-TV1 <> HDMI
>> >> > - mixer1 <> TCON-TV0 <> HDMI
>> >> > - mixer1 <> TCON-TV1 <> HDMI
>> >> >
>> >> > Please review.
>> >> >
>> >> > Best regards,
>> >> > Jernej
>> >> >
>> >> > Changes from v1:
>> >> > - Split DT bindings patch and updated description
>> >> > - Split HDMI PHY patch
>> >> > - Move header file from TCON TOP patch to dt bindings patch
>> >> > - Added Rob reviewed-by tag
>> >> > - Used clk_hw_register_gate() instead of custom gate registration code
>> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
>> >> >
>> >> > new patches were added.
>> >> >
>> >> > - Droped mixer index quirk patch
>> >> > - Reworked TCON support for TCON TOP
>> >> > - Updated commit messages
>> >> >
>> >> > Jernej Skrabec (27):
>> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >> >
>> >> > clocks
>> >> >
>> >> > clk: sunxi-ng: r40: Export video PLLs
>> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> >> > drm/sun4i: Add TCON TOP driver
>> >> > drm/sun4i: Fix releasing node when enumerating enpoints
>> >> > drm/sun4i: Split out code for enumerating endpoints in output port
>> >> > drm/sun4i: Add support for traversing graph with TCON TOP
>> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> >> > drm/sun4i: tcon: Add support for tcon-top gate
>> >> > drm/sun4i: tcon: Generalize engine search algorithm
>> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> >> > drm/sun4i: Add support for R40 TV TCON
>> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> >> > drm/sun4i: Add support for R40 mixers
>> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> >> > drm/sun4i: Enable DW HDMI PHY clock
>> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >> >
>> >> > driver
>> >> >
>> >> > drm/sun4i: Add support for A64 HDMI PHY
>> >> > drm: of: Export drm_crtc_port_mask()
>> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>> >>
>> >> Tested whole series on top of linux-next.
>> >>
>> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
>> >
>> > Thanks!
>>
>> I've V40 board, which is same as R40. I'm able to detect the HDMI but
>> seems edid not detecting properly.
>>
>> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
>> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
>> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
>> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm display-engine:
>> bound 1c73000.lcd-controller (ops 0xc0747a28)
>> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
>> v1.32a with HDCP (sun8i_dw_hdmi_phy)
>> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
>> I2C bus driver
>> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
>> [ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 1.085098] [drm] No driver support for vblank timestamp query. [
>> 1.091055] [drm] Cannot find any crtc or sizes
>> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
>> display-engine on minor 0
>
> This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> different to R40) and board DTS?
same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
[1] https://paste.ubuntu.com/p/wqVz38BHrM/
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 12:58 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-18 12:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 14, 2018 at 10:59 PM, Jernej ?krabec
<jernej.skrabec@siol.net> wrote:
> Dne ?etrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
>> On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec@siol.net>
> wrote:
>> > Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
>> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
>> >
>> > wrote:
>> >> > This series adds support for R40 HDMI pipeline. It is a bit special
>> >> > than other already supported pipelines because it has additional unit
>> >> > called TCON TOP responsible for relationship configuration between
>> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
>> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> >> > and TV encoders.
>> >> >
>> >> > However, it seems that TCON TOP will become a norm, since newer
>> >> > Allwinner SoCs like H6 also have this unit.
>> >> >
>> >> > I tested different possible configurations:
>> >> > - mixer0 <> TCON-TV0 <> HDMI
>> >> > - mixer0 <> TCON-TV1 <> HDMI
>> >> > - mixer1 <> TCON-TV0 <> HDMI
>> >> > - mixer1 <> TCON-TV1 <> HDMI
>> >> >
>> >> > Please review.
>> >> >
>> >> > Best regards,
>> >> > Jernej
>> >> >
>> >> > Changes from v1:
>> >> > - Split DT bindings patch and updated description
>> >> > - Split HDMI PHY patch
>> >> > - Move header file from TCON TOP patch to dt bindings patch
>> >> > - Added Rob reviewed-by tag
>> >> > - Used clk_hw_register_gate() instead of custom gate registration code
>> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
>> >> >
>> >> > new patches were added.
>> >> >
>> >> > - Droped mixer index quirk patch
>> >> > - Reworked TCON support for TCON TOP
>> >> > - Updated commit messages
>> >> >
>> >> > Jernej Skrabec (27):
>> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >> >
>> >> > clocks
>> >> >
>> >> > clk: sunxi-ng: r40: Export video PLLs
>> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> >> > drm/sun4i: Add TCON TOP driver
>> >> > drm/sun4i: Fix releasing node when enumerating enpoints
>> >> > drm/sun4i: Split out code for enumerating endpoints in output port
>> >> > drm/sun4i: Add support for traversing graph with TCON TOP
>> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> >> > drm/sun4i: tcon: Add support for tcon-top gate
>> >> > drm/sun4i: tcon: Generalize engine search algorithm
>> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> >> > drm/sun4i: Add support for R40 TV TCON
>> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> >> > drm/sun4i: Add support for R40 mixers
>> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> >> > drm/sun4i: Enable DW HDMI PHY clock
>> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >> >
>> >> > driver
>> >> >
>> >> > drm/sun4i: Add support for A64 HDMI PHY
>> >> > drm: of: Export drm_crtc_port_mask()
>> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>> >>
>> >> Tested whole series on top of linux-next.
>> >>
>> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
>> >
>> > Thanks!
>>
>> I've V40 board, which is same as R40. I'm able to detect the HDMI but
>> seems edid not detecting properly.
>>
>> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
>> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
>> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
>> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm display-engine:
>> bound 1c73000.lcd-controller (ops 0xc0747a28)
>> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
>> v1.32a with HDCP (sun8i_dw_hdmi_phy)
>> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
>> I2C bus driver
>> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
>> [ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 1.085098] [drm] No driver support for vblank timestamp query. [
>> 1.091055] [drm] Cannot find any crtc or sizes
>> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
>> display-engine on minor 0
>
> This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> different to R40) and board DTS?
same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
[1] https://paste.ubuntu.com/p/wqVz38BHrM/
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 12:58 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-18 12:58 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
On Thu, Jun 14, 2018 at 10:59 PM, Jernej =C5=A0krabec
<jernej.skrabec@siol.net> wrote:
> Dne =C4=8Detrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a=
):
>> On Thu, Jun 14, 2018 at 8:04 PM, Jernej =C5=A0krabec <jernej.skrabec@sio=
l.net>
> wrote:
>> > Dne =C4=8Detrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisa=
l(a):
>> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.=
net>
>> >
>> > wrote:
>> >> > This series adds support for R40 HDMI pipeline. It is a bit special
>> >> > than other already supported pipelines because it has additional un=
it
>> >> > called TCON TOP responsible for relationship configuration between
>> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for D=
SI
>> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> >> > and TV encoders.
>> >> >
>> >> > However, it seems that TCON TOP will become a norm, since newer
>> >> > Allwinner SoCs like H6 also have this unit.
>> >> >
>> >> > I tested different possible configurations:
>> >> > - mixer0 <> TCON-TV0 <> HDMI
>> >> > - mixer0 <> TCON-TV1 <> HDMI
>> >> > - mixer1 <> TCON-TV0 <> HDMI
>> >> > - mixer1 <> TCON-TV1 <> HDMI
>> >> >
>> >> > Please review.
>> >> >
>> >> > Best regards,
>> >> > Jernej
>> >> >
>> >> > Changes from v1:
>> >> > - Split DT bindings patch and updated description
>> >> > - Split HDMI PHY patch
>> >> > - Move header file from TCON TOP patch to dt bindings patch
>> >> > - Added Rob reviewed-by tag
>> >> > - Used clk_hw_register_gate() instead of custom gate registration c=
ode
>> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot =
of
>> >> >
>> >> > new patches were added.
>> >> >
>> >> > - Droped mixer index quirk patch
>> >> > - Reworked TCON support for TCON TOP
>> >> > - Updated commit messages
>> >> >
>> >> > Jernej Skrabec (27):
>> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >> >
>> >> > clocks
>> >> >
>> >> > clk: sunxi-ng: r40: Export video PLLs
>> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> >> > drm/sun4i: Add TCON TOP driver
>> >> > drm/sun4i: Fix releasing node when enumerating enpoints
>> >> > drm/sun4i: Split out code for enumerating endpoints in output por=
t
>> >> > drm/sun4i: Add support for traversing graph with TCON TOP
>> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> >> > drm/sun4i: tcon: Add support for tcon-top gate
>> >> > drm/sun4i: tcon: Generalize engine search algorithm
>> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> >> > drm/sun4i: Add support for R40 TV TCON
>> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> >> > drm/sun4i: Add support for R40 mixers
>> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> >> > drm/sun4i: Enable DW HDMI PHY clock
>> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >> >
>> >> > driver
>> >> >
>> >> > drm/sun4i: Add support for A64 HDMI PHY
>> >> > drm: of: Export drm_crtc_port_mask()
>> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>> >>
>> >> Tested whole series on top of linux-next.
>> >>
>> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
>> >
>> > Thanks!
>>
>> I've V40 board, which is same as R40. I'm able to detect the HDMI but
>> seems edid not detecting properly.
>>
>> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
>> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
>> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
>> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm display-engin=
e:
>> bound 1c73000.lcd-controller (ops 0xc0747a28)
>> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
>> v1.32a with HDCP (sun8i_dw_hdmi_phy)
>> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
>> I2C bus driver
>> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a=
298)
>> [ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013=
).
>> [ 1.085098] [drm] No driver support for vblank timestamp query. [
>> 1.091055] [drm] Cannot find any crtc or sizes
>> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
>> display-engine on minor 0
>
> This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> different to R40) and board DTS?
same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
[1] https://paste.ubuntu.com/p/wqVz38BHrM/
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 12:58 ` Jagan Teki
0 siblings, 0 replies; 201+ messages in thread
From: Jagan Teki @ 2018-06-18 12:58 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA, Sean Paul,
Mark Rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
On Thu, Jun 14, 2018 at 10:59 PM, Jernej Škrabec
<jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
>> On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net>
> wrote:
>> > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
>> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec <jernej.skrabec@siol.net>
>> >
>> > wrote:
>> >> > This series adds support for R40 HDMI pipeline. It is a bit special
>> >> > than other already supported pipelines because it has additional unit
>> >> > called TCON TOP responsible for relationship configuration between
>> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for DSI
>> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
>> >> > and TV encoders.
>> >> >
>> >> > However, it seems that TCON TOP will become a norm, since newer
>> >> > Allwinner SoCs like H6 also have this unit.
>> >> >
>> >> > I tested different possible configurations:
>> >> > - mixer0 <> TCON-TV0 <> HDMI
>> >> > - mixer0 <> TCON-TV1 <> HDMI
>> >> > - mixer1 <> TCON-TV0 <> HDMI
>> >> > - mixer1 <> TCON-TV1 <> HDMI
>> >> >
>> >> > Please review.
>> >> >
>> >> > Best regards,
>> >> > Jernej
>> >> >
>> >> > Changes from v1:
>> >> > - Split DT bindings patch and updated description
>> >> > - Split HDMI PHY patch
>> >> > - Move header file from TCON TOP patch to dt bindings patch
>> >> > - Added Rob reviewed-by tag
>> >> > - Used clk_hw_register_gate() instead of custom gate registration code
>> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot of
>> >> >
>> >> > new patches were added.
>> >> >
>> >> > - Droped mixer index quirk patch
>> >> > - Reworked TCON support for TCON TOP
>> >> > - Updated commit messages
>> >> >
>> >> > Jernej Skrabec (27):
>> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
>> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
>> >> >
>> >> > clocks
>> >> >
>> >> > clk: sunxi-ng: r40: Export video PLLs
>> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
>> >> > drm/sun4i: Add TCON TOP driver
>> >> > drm/sun4i: Fix releasing node when enumerating enpoints
>> >> > drm/sun4i: Split out code for enumerating endpoints in output port
>> >> > drm/sun4i: Add support for traversing graph with TCON TOP
>> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
>> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
>> >> > drm/sun4i: tcon: Add support for tcon-top gate
>> >> > drm/sun4i: tcon: Generalize engine search algorithm
>> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
>> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
>> >> > drm/sun4i: Add support for R40 TV TCON
>> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
>> >> > drm/sun4i: Add support for R40 mixers
>> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
>> >> > drm/sun4i: Enable DW HDMI PHY clock
>> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
>> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
>> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
>> >> >
>> >> > driver
>> >> >
>> >> > drm/sun4i: Add support for A64 HDMI PHY
>> >> > drm: of: Export drm_crtc_port_mask()
>> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
>> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
>> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
>> >>
>> >> Tested whole series on top of linux-next.
>> >>
>> >> Tested-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>> >
>> > Thanks!
>>
>> I've V40 board, which is same as R40. I'm able to detect the HDMI but
>> seems edid not detecting properly.
>>
>> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
>> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
>> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
>> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm display-engine:
>> bound 1c73000.lcd-controller (ops 0xc0747a28)
>> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
>> v1.32a with HDCP (sun8i_dw_hdmi_phy)
>> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
>> I2C bus driver
>> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops 0xc074a298)
>> [ 1.078484] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [ 1.085098] [drm] No driver support for vblank timestamp query. [
>> 1.091055] [drm] Cannot find any crtc or sizes
>> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
>> display-engine on minor 0
>
> This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> different to R40) and board DTS?
same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
[1] https://paste.ubuntu.com/p/wqVz38BHrM/
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 14:43 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-18 14:43 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 10:59 PM, Jernej Škrabec
>
> <jernej.skrabec@siol.net> wrote:
> > Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> >> On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> >> >> <jernej.skrabec@siol.net>
> >> >
> >> > wrote:
> >> >> > This series adds support for R40 HDMI pipeline. It is a bit special
> >> >> > than other already supported pipelines because it has additional
> >> >> > unit
> >> >> > called TCON TOP responsible for relationship configuration between
> >> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for
> >> >> > DSI
> >> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> >> >> > and TV encoders.
> >> >> >
> >> >> > However, it seems that TCON TOP will become a norm, since newer
> >> >> > Allwinner SoCs like H6 also have this unit.
> >> >> >
> >> >> > I tested different possible configurations:
> >> >> > - mixer0 <> TCON-TV0 <> HDMI
> >> >> > - mixer0 <> TCON-TV1 <> HDMI
> >> >> > - mixer1 <> TCON-TV0 <> HDMI
> >> >> > - mixer1 <> TCON-TV1 <> HDMI
> >> >> >
> >> >> > Please review.
> >> >> >
> >> >> > Best regards,
> >> >> > Jernej
> >> >> >
> >> >> > Changes from v1:
> >> >> > - Split DT bindings patch and updated description
> >> >> > - Split HDMI PHY patch
> >> >> > - Move header file from TCON TOP patch to dt bindings patch
> >> >> > - Added Rob reviewed-by tag
> >> >> > - Used clk_hw_register_gate() instead of custom gate registration
> >> >> > code
> >> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot
> >> >> > of
> >> >> >
> >> >> > new patches were added.
> >> >> >
> >> >> > - Droped mixer index quirk patch
> >> >> > - Reworked TCON support for TCON TOP
> >> >> > - Updated commit messages
> >> >> >
> >> >> > Jernej Skrabec (27):
> >> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> >> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >> >> >
> >> >> > clocks
> >> >> >
> >> >> > clk: sunxi-ng: r40: Export video PLLs
> >> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> >> >> > drm/sun4i: Add TCON TOP driver
> >> >> > drm/sun4i: Fix releasing node when enumerating enpoints
> >> >> > drm/sun4i: Split out code for enumerating endpoints in output port
> >> >> > drm/sun4i: Add support for traversing graph with TCON TOP
> >> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> >> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> >> >> > drm/sun4i: tcon: Add support for tcon-top gate
> >> >> > drm/sun4i: tcon: Generalize engine search algorithm
> >> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> >> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> >> >> > drm/sun4i: Add support for R40 TV TCON
> >> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> >> >> > drm/sun4i: Add support for R40 mixers
> >> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> >> >> > drm/sun4i: Enable DW HDMI PHY clock
> >> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> >> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> >> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >> >> >
> >> >> > driver
> >> >> >
> >> >> > drm/sun4i: Add support for A64 HDMI PHY
> >> >> > drm: of: Export drm_crtc_port_mask()
> >> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> >> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
> >> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
> >> >>
> >> >> Tested whole series on top of linux-next.
> >> >>
> >> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> >> >
> >> > Thanks!
> >>
> >> I've V40 board, which is same as R40. I'm able to detect the HDMI but
> >> seems edid not detecting properly.
> >>
> >> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
> >> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
> >> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> >> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> >> display-engine:
> >> bound 1c73000.lcd-controller (ops 0xc0747a28)
> >> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
> >> v1.32a with HDCP (sun8i_dw_hdmi_phy)
> >> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
> >> I2C bus driver
> >> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops
> >> 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp caching Rev 2
> >> (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> >> timestamp query. [ 1.091055] [drm] Cannot find any crtc or sizes
> >> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> >> display-engine on minor 0
> >
> > This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> > different to R40) and board DTS?
>
> same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
>
> [1] https://paste.ubuntu.com/p/wqVz38BHrM/
This patch looks like exactly the same as mine for BananaPi M2U, so there
should be no issues.
What about VCC-HDMI? Is powered? Can you measure it to check?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 14:43 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-18 14:43 UTC (permalink / raw)
To: linux-arm-kernel
Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 10:59 PM, Jernej ?krabec
>
> <jernej.skrabec@siol.net> wrote:
> > Dne ?etrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> >> On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> >> >> <jernej.skrabec@siol.net>
> >> >
> >> > wrote:
> >> >> > This series adds support for R40 HDMI pipeline. It is a bit special
> >> >> > than other already supported pipelines because it has additional
> >> >> > unit
> >> >> > called TCON TOP responsible for relationship configuration between
> >> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for
> >> >> > DSI
> >> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> >> >> > and TV encoders.
> >> >> >
> >> >> > However, it seems that TCON TOP will become a norm, since newer
> >> >> > Allwinner SoCs like H6 also have this unit.
> >> >> >
> >> >> > I tested different possible configurations:
> >> >> > - mixer0 <> TCON-TV0 <> HDMI
> >> >> > - mixer0 <> TCON-TV1 <> HDMI
> >> >> > - mixer1 <> TCON-TV0 <> HDMI
> >> >> > - mixer1 <> TCON-TV1 <> HDMI
> >> >> >
> >> >> > Please review.
> >> >> >
> >> >> > Best regards,
> >> >> > Jernej
> >> >> >
> >> >> > Changes from v1:
> >> >> > - Split DT bindings patch and updated description
> >> >> > - Split HDMI PHY patch
> >> >> > - Move header file from TCON TOP patch to dt bindings patch
> >> >> > - Added Rob reviewed-by tag
> >> >> > - Used clk_hw_register_gate() instead of custom gate registration
> >> >> > code
> >> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot
> >> >> > of
> >> >> >
> >> >> > new patches were added.
> >> >> >
> >> >> > - Droped mixer index quirk patch
> >> >> > - Reworked TCON support for TCON TOP
> >> >> > - Updated commit messages
> >> >> >
> >> >> > Jernej Skrabec (27):
> >> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> >> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >> >> >
> >> >> > clocks
> >> >> >
> >> >> > clk: sunxi-ng: r40: Export video PLLs
> >> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> >> >> > drm/sun4i: Add TCON TOP driver
> >> >> > drm/sun4i: Fix releasing node when enumerating enpoints
> >> >> > drm/sun4i: Split out code for enumerating endpoints in output port
> >> >> > drm/sun4i: Add support for traversing graph with TCON TOP
> >> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> >> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> >> >> > drm/sun4i: tcon: Add support for tcon-top gate
> >> >> > drm/sun4i: tcon: Generalize engine search algorithm
> >> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> >> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> >> >> > drm/sun4i: Add support for R40 TV TCON
> >> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> >> >> > drm/sun4i: Add support for R40 mixers
> >> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> >> >> > drm/sun4i: Enable DW HDMI PHY clock
> >> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> >> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> >> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >> >> >
> >> >> > driver
> >> >> >
> >> >> > drm/sun4i: Add support for A64 HDMI PHY
> >> >> > drm: of: Export drm_crtc_port_mask()
> >> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> >> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
> >> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
> >> >>
> >> >> Tested whole series on top of linux-next.
> >> >>
> >> >> Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> >> >
> >> > Thanks!
> >>
> >> I've V40 board, which is same as R40. I'm able to detect the HDMI but
> >> seems edid not detecting properly.
> >>
> >> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
> >> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
> >> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> >> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> >> display-engine:
> >> bound 1c73000.lcd-controller (ops 0xc0747a28)
> >> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
> >> v1.32a with HDCP (sun8i_dw_hdmi_phy)
> >> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
> >> I2C bus driver
> >> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops
> >> 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp caching Rev 2
> >> (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> >> timestamp query. [ 1.091055] [drm] Cannot find any crtc or sizes
> >> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> >> display-engine on minor 0
> >
> > This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> > different to R40) and board DTS?
>
> same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
>
> [1] https://paste.ubuntu.com/p/wqVz38BHrM/
This patch looks like exactly the same as mine for BananaPi M2U, so there
should be no issues.
What about VCC-HDMI? Is powered? Can you measure it to check?
Best regards,
Jernej
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 14:43 ` Jernej Škrabec
0 siblings, 0 replies; 201+ messages in thread
From: Jernej Škrabec @ 2018-06-18 14:43 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA, Sean Paul,
Mark Rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki napisal(a):
> On Thu, Jun 14, 2018 at 10:59 PM, Jernej Škrabec
>
> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> > Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki napisal(a):
> >> On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec@siol.net>
> >
> > wrote:
> >> > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki napisal(a):
> >> >> On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> >> >> <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> >> >
> >> > wrote:
> >> >> > This series adds support for R40 HDMI pipeline. It is a bit special
> >> >> > than other already supported pipelines because it has additional
> >> >> > unit
> >> >> > called TCON TOP responsible for relationship configuration between
> >> >> > mixers, TCONs and HDMI. Additionally, it has additional gates for
> >> >> > DSI
> >> >> > and TV TCONs, TV encoder clock settings and pin muxing between LCD
> >> >> > and TV encoders.
> >> >> >
> >> >> > However, it seems that TCON TOP will become a norm, since newer
> >> >> > Allwinner SoCs like H6 also have this unit.
> >> >> >
> >> >> > I tested different possible configurations:
> >> >> > - mixer0 <> TCON-TV0 <> HDMI
> >> >> > - mixer0 <> TCON-TV1 <> HDMI
> >> >> > - mixer1 <> TCON-TV0 <> HDMI
> >> >> > - mixer1 <> TCON-TV1 <> HDMI
> >> >> >
> >> >> > Please review.
> >> >> >
> >> >> > Best regards,
> >> >> > Jernej
> >> >> >
> >> >> > Changes from v1:
> >> >> > - Split DT bindings patch and updated description
> >> >> > - Split HDMI PHY patch
> >> >> > - Move header file from TCON TOP patch to dt bindings patch
> >> >> > - Added Rob reviewed-by tag
> >> >> > - Used clk_hw_register_gate() instead of custom gate registration
> >> >> > code
> >> >> > - Reworked TCON TOP to be part of of-graph. Because of that, a lot
> >> >> > of
> >> >> >
> >> >> > new patches were added.
> >> >> >
> >> >> > - Droped mixer index quirk patch
> >> >> > - Reworked TCON support for TCON TOP
> >> >> > - Updated commit messages
> >> >> >
> >> >> > Jernej Skrabec (27):
> >> >> > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> >> >> > clk: sunxi-ng: r40: Allow setting parent rate to display related
> >> >> >
> >> >> > clocks
> >> >> >
> >> >> > clk: sunxi-ng: r40: Export video PLLs
> >> >> > dt-bindings: display: sunxi-drm: Add TCON TOP description
> >> >> > drm/sun4i: Add TCON TOP driver
> >> >> > drm/sun4i: Fix releasing node when enumerating enpoints
> >> >> > drm/sun4i: Split out code for enumerating endpoints in output port
> >> >> > drm/sun4i: Add support for traversing graph with TCON TOP
> >> >> > drm/sun4i: Don't skip TCONs if they don't have channel 0
> >> >> > dt-bindings: display: sun4i-drm: Add R40 TV TCON description
> >> >> > drm/sun4i: tcon: Add support for tcon-top gate
> >> >> > drm/sun4i: tcon: Generalize engine search algorithm
> >> >> > drm/sun4i: Don't check for LVDS and RGB when TCON has only ch1
> >> >> > drm/sun4i: Don't check for panel or bridge on TV TCONs
> >> >> > drm/sun4i: Add support for R40 TV TCON
> >> >> > dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
> >> >> > drm/sun4i: Add support for R40 mixers
> >> >> > dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
> >> >> > drm/sun4i: Enable DW HDMI PHY clock
> >> >> > drm/sun4i: Don't change clock bits in DW HDMI PHY driver
> >> >> > drm/sun4i: DW HDMI PHY: Add support for second PLL
> >> >> > drm/sun4i: Add support for second clock parent to DW HDMI PHY clk
> >> >> >
> >> >> > driver
> >> >> >
> >> >> > drm/sun4i: Add support for A64 HDMI PHY
> >> >> > drm: of: Export drm_crtc_port_mask()
> >> >> > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> >> >> > ARM: dts: sun8i: r40: Add HDMI pipeline
> >> >> > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2 Ultra
> >> >>
> >> >> Tested whole series on top of linux-next.
> >> >>
> >> >> Tested-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> >> >
> >> > Thanks!
> >>
> >> I've V40 board, which is same as R40. I'm able to detect the HDMI but
> >> seems edid not detecting properly.
> >>
> >> [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer (ops
> >> 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound 1200000.mixer
> >> (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> >> 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> >> display-engine:
> >> bound 1c73000.lcd-controller (ops 0xc0747a28)
> >> [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX controller
> >> v1.32a with HDCP (sun8i_dw_hdmi_phy)
> >> [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered DesignWare HDMI
> >> I2C bus driver
> >> [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi (ops
> >> 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp caching Rev 2
> >> (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> >> timestamp query. [ 1.091055] [drm] Cannot find any crtc or sizes
> >> [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> >> display-engine on minor 0
> >
> > This seems like DT issue. Can you post somewhere your V40 DTSI (if it is
> > different to R40) and board DTS?
>
> same dtsi shared between r40 and v40, here is board dts support for HDMI[1]
>
> [1] https://paste.ubuntu.com/p/wqVz38BHrM/
This patch looks like exactly the same as mine for BananaPi M2U, so there
should be no issues.
What about VCC-HDMI? Is powered? Can you measure it to check?
Best regards,
Jernej
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
2018-06-18 14:43 ` Jernej Škrabec
(?)
@ 2018-06-18 18:49 ` Icenowy Zheng
-1 siblings, 0 replies; 201+ messages in thread
From: Icenowy Zheng @ 2018-06-18 18:49 UTC (permalink / raw)
To: jernej.skrabec, Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie, gustavo,
maarten.lankhorst, Sean Paul, Mark Rutland, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-clk,
linux-sunxi
在 2018-06-18一的 16:43 +0200，Jernej Škrabec写道：
> Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki
> napisal(a):
> > On Thu, Jun 14, 2018 at 10:59 PM, Jernej Škrabec
> >
> > <jernej.skrabec@siol.net> wrote:
> > > Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki
> > > napisal(a):
> > > > On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec
> > > > @siol.net>
> > >
> > > wrote:
> > > > > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki
> > > > > napisal(a):
> > > > > > On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> > > > > > <jernej.skrabec@siol.net>
> > > > >
> > > > > wrote:
> > > > > > > This series adds support for R40 HDMI pipeline. It is a
> > > > > > > bit special
> > > > > > > than other already supported pipelines because it has
> > > > > > > additional
> > > > > > > unit
> > > > > > > called TCON TOP responsible for relationship
> > > > > > > configuration between
> > > > > > > mixers, TCONs and HDMI. Additionally, it has additional
> > > > > > > gates for
> > > > > > > DSI
> > > > > > > and TV TCONs, TV encoder clock settings and pin muxing
> > > > > > > between LCD
> > > > > > > and TV encoders.
> > > > > > >
> > > > > > > However, it seems that TCON TOP will become a norm, since
> > > > > > > newer
> > > > > > > Allwinner SoCs like H6 also have this unit.
> > > > > > >
> > > > > > > I tested different possible configurations:
> > > > > > > - mixer0 <> TCON-TV0 <> HDMI
> > > > > > > - mixer0 <> TCON-TV1 <> HDMI
> > > > > > > - mixer1 <> TCON-TV0 <> HDMI
> > > > > > > - mixer1 <> TCON-TV1 <> HDMI
> > > > > > >
> > > > > > > Please review.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jernej
> > > > > > >
> > > > > > > Changes from v1:
> > > > > > > - Split DT bindings patch and updated description
> > > > > > > - Split HDMI PHY patch
> > > > > > > - Move header file from TCON TOP patch to dt bindings
> > > > > > > patch
> > > > > > > - Added Rob reviewed-by tag
> > > > > > > - Used clk_hw_register_gate() instead of custom gate
> > > > > > > registration
> > > > > > > code
> > > > > > > - Reworked TCON TOP to be part of of-graph. Because of
> > > > > > > that, a lot
> > > > > > > of
> > > > > > >
> > > > > > > new patches were added.
> > > > > > >
> > > > > > > - Droped mixer index quirk patch
> > > > > > > - Reworked TCON support for TCON TOP
> > > > > > > - Updated commit messages
> > > > > > >
> > > > > > > Jernej Skrabec (27):
> > > > > > > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > > > > > > clk: sunxi-ng: r40: Allow setting parent rate to
> > > > > > > display related
> > > > > > >
> > > > > > > clocks
> > > > > > >
> > > > > > > clk: sunxi-ng: r40: Export video PLLs
> > > > > > > dt-bindings: display: sunxi-drm: Add TCON TOP
> > > > > > > description
> > > > > > > drm/sun4i: Add TCON TOP driver
> > > > > > > drm/sun4i: Fix releasing node when enumerating enpoints
> > > > > > > drm/sun4i: Split out code for enumerating endpoints in
> > > > > > > output port
> > > > > > > drm/sun4i: Add support for traversing graph with TCON
> > > > > > > TOP
> > > > > > > drm/sun4i: Don't skip TCONs if they don't have channel
> > > > > > > 0
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 TV TCON
> > > > > > > description
> > > > > > > drm/sun4i: tcon: Add support for tcon-top gate
> > > > > > > drm/sun4i: tcon: Generalize engine search algorithm
> > > > > > > drm/sun4i: Don't check for LVDS and RGB when TCON has
> > > > > > > only ch1
> > > > > > > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > > > > > > drm/sun4i: Add support for R40 TV TCON
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 mixer
> > > > > > > compatibles
> > > > > > > drm/sun4i: Add support for R40 mixers
> > > > > > > dt-bindings: display: sun4i-drm: Add description of A64
> > > > > > > HDMI PHY
> > > > > > > drm/sun4i: Enable DW HDMI PHY clock
> > > > > > > drm/sun4i: Don't change clock bits in DW HDMI PHY
> > > > > > > driver
> > > > > > > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > > > > > > drm/sun4i: Add support for second clock parent to DW
> > > > > > > HDMI PHY clk
> > > > > > >
> > > > > > > driver
> > > > > > >
> > > > > > > drm/sun4i: Add support for A64 HDMI PHY
> > > > > > > drm: of: Export drm_crtc_port_mask()
> > > > > > > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > > > > > > ARM: dts: sun8i: r40: Add HDMI pipeline
> > > > > > > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2
> > > > > > > Ultra
> > > > > >
> > > > > > Tested whole series on top of linux-next.
> > > > > >
> > > > > > Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > >
> > > > > Thanks!
> > > >
> > > > I've V40 board, which is same as R40. I'm able to detect the
> > > > HDMI but
> > > > seems edid not detecting properly.
> > > >
> > > > [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer
> > > > (ops
> > > > 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound
> > > > 1200000.mixer
> > > > (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> > > > 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> > > > display-engine:
> > > > bound 1c73000.lcd-controller (ops 0xc0747a28)
> > > > [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX
> > > > controller
> > > > v1.32a with HDCP (sun8i_dw_hdmi_phy)
> > > > [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered
> > > > DesignWare HDMI
> > > > I2C bus driver
> > > > [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi
> > > > (ops
> > > > 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp
> > > > caching Rev 2
> > > > (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> > > > timestamp query. [ 1.091055] [drm] Cannot find any crtc or
> > > > sizes
> > > > [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> > > > display-engine on minor 0
> > >
> > > This seems like DT issue. Can you post somewhere your V40 DTSI
> > > (if it is
> > > different to R40) and board DTS?
> >
> > same dtsi shared between r40 and v40, here is board dts support for
> > HDMI[1]
> >
> > [1] https://paste.ubuntu.com/p/wqVz38BHrM/
>
> This patch looks like exactly the same as mine for BananaPi M2U, so
> there
> should be no issues.
As I know, M2B is designed to be compatible with M2U, so most things
should be the same. The stock firmware even use the same images for
both M2U and M2B.
>
> What about VCC-HDMI? Is powered? Can you measure it to check?
>
> Best regards,
> Jernej
>
>
>
^ permalink raw reply [flat|nested] 201+ messages in thread
* [linux-sunxi] [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 18:49 ` Icenowy Zheng
0 siblings, 0 replies; 201+ messages in thread
From: Icenowy Zheng @ 2018-06-18 18:49 UTC (permalink / raw)
To: linux-arm-kernel
? 2018-06-18?? 16:43 +0200?Jernej ?krabec???
> Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki
> napisal(a):
> > On Thu, Jun 14, 2018 at 10:59 PM, Jernej ?krabec
> >
> > <jernej.skrabec@siol.net> wrote:
> > > Dne ?etrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki
> > > napisal(a):
> > > > On Thu, Jun 14, 2018 at 8:04 PM, Jernej ?krabec <jernej.skrabec
> > > > @siol.net>
> > >
> > > wrote:
> > > > > Dne ?etrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki
> > > > > napisal(a):
> > > > > > On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> > > > > > <jernej.skrabec@siol.net>
> > > > >
> > > > > wrote:
> > > > > > > This series adds support for R40 HDMI pipeline. It is a
> > > > > > > bit special
> > > > > > > than other already supported pipelines because it has
> > > > > > > additional
> > > > > > > unit
> > > > > > > called TCON TOP responsible for relationship
> > > > > > > configuration between
> > > > > > > mixers, TCONs and HDMI. Additionally, it has additional
> > > > > > > gates for
> > > > > > > DSI
> > > > > > > and TV TCONs, TV encoder clock settings and pin muxing
> > > > > > > between LCD
> > > > > > > and TV encoders.
> > > > > > >
> > > > > > > However, it seems that TCON TOP will become a norm, since
> > > > > > > newer
> > > > > > > Allwinner SoCs like H6 also have this unit.
> > > > > > >
> > > > > > > I tested different possible configurations:
> > > > > > > - mixer0 <> TCON-TV0 <> HDMI
> > > > > > > - mixer0 <> TCON-TV1 <> HDMI
> > > > > > > - mixer1 <> TCON-TV0 <> HDMI
> > > > > > > - mixer1 <> TCON-TV1 <> HDMI
> > > > > > >
> > > > > > > Please review.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jernej
> > > > > > >
> > > > > > > Changes from v1:
> > > > > > > - Split DT bindings patch and updated description
> > > > > > > - Split HDMI PHY patch
> > > > > > > - Move header file from TCON TOP patch to dt bindings
> > > > > > > patch
> > > > > > > - Added Rob reviewed-by tag
> > > > > > > - Used clk_hw_register_gate() instead of custom gate
> > > > > > > registration
> > > > > > > code
> > > > > > > - Reworked TCON TOP to be part of of-graph. Because of
> > > > > > > that, a lot
> > > > > > > of
> > > > > > >
> > > > > > > new patches were added.
> > > > > > >
> > > > > > > - Droped mixer index quirk patch
> > > > > > > - Reworked TCON support for TCON TOP
> > > > > > > - Updated commit messages
> > > > > > >
> > > > > > > Jernej Skrabec (27):
> > > > > > > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > > > > > > clk: sunxi-ng: r40: Allow setting parent rate to
> > > > > > > display related
> > > > > > >
> > > > > > > clocks
> > > > > > >
> > > > > > > clk: sunxi-ng: r40: Export video PLLs
> > > > > > > dt-bindings: display: sunxi-drm: Add TCON TOP
> > > > > > > description
> > > > > > > drm/sun4i: Add TCON TOP driver
> > > > > > > drm/sun4i: Fix releasing node when enumerating enpoints
> > > > > > > drm/sun4i: Split out code for enumerating endpoints in
> > > > > > > output port
> > > > > > > drm/sun4i: Add support for traversing graph with TCON
> > > > > > > TOP
> > > > > > > drm/sun4i: Don't skip TCONs if they don't have channel
> > > > > > > 0
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 TV TCON
> > > > > > > description
> > > > > > > drm/sun4i: tcon: Add support for tcon-top gate
> > > > > > > drm/sun4i: tcon: Generalize engine search algorithm
> > > > > > > drm/sun4i: Don't check for LVDS and RGB when TCON has
> > > > > > > only ch1
> > > > > > > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > > > > > > drm/sun4i: Add support for R40 TV TCON
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 mixer
> > > > > > > compatibles
> > > > > > > drm/sun4i: Add support for R40 mixers
> > > > > > > dt-bindings: display: sun4i-drm: Add description of A64
> > > > > > > HDMI PHY
> > > > > > > drm/sun4i: Enable DW HDMI PHY clock
> > > > > > > drm/sun4i: Don't change clock bits in DW HDMI PHY
> > > > > > > driver
> > > > > > > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > > > > > > drm/sun4i: Add support for second clock parent to DW
> > > > > > > HDMI PHY clk
> > > > > > >
> > > > > > > driver
> > > > > > >
> > > > > > > drm/sun4i: Add support for A64 HDMI PHY
> > > > > > > drm: of: Export drm_crtc_port_mask()
> > > > > > > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > > > > > > ARM: dts: sun8i: r40: Add HDMI pipeline
> > > > > > > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2
> > > > > > > Ultra
> > > > > >
> > > > > > Tested whole series on top of linux-next.
> > > > > >
> > > > > > Tested-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > >
> > > > > Thanks!
> > > >
> > > > I've V40 board, which is same as R40. I'm able to detect the
> > > > HDMI but
> > > > seems edid not detecting properly.
> > > >
> > > > [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer
> > > > (ops
> > > > 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound
> > > > 1200000.mixer
> > > > (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> > > > 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> > > > display-engine:
> > > > bound 1c73000.lcd-controller (ops 0xc0747a28)
> > > > [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX
> > > > controller
> > > > v1.32a with HDCP (sun8i_dw_hdmi_phy)
> > > > [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered
> > > > DesignWare HDMI
> > > > I2C bus driver
> > > > [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi
> > > > (ops
> > > > 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp
> > > > caching Rev 2
> > > > (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> > > > timestamp query. [ 1.091055] [drm] Cannot find any crtc or
> > > > sizes
> > > > [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> > > > display-engine on minor 0
> > >
> > > This seems like DT issue. Can you post somewhere your V40 DTSI
> > > (if it is
> > > different to R40) and board DTS?
> >
> > same dtsi shared between r40 and v40, here is board dts support for
> > HDMI[1]
> >
> > [1] https://paste.ubuntu.com/p/wqVz38BHrM/
>
> This patch looks like exactly the same as mine for BananaPi M2U, so
> there
> should be no issues.
As I know, M2B is designed to be compatible with M2U, so most things
should be the same. The stock firmware even use the same images for
both M2U and M2B.
>
> What about VCC-HDMI? Is powered? Can you measure it to check?
>
> Best regards,
> Jernej
>
>
>
^ permalink raw reply [flat|nested] 201+ messages in thread
* Re: [PATCH v2 00/27] Add support for R40 HDMI pipeline
@ 2018-06-18 18:49 ` Icenowy Zheng
0 siblings, 0 replies; 201+ messages in thread
From: Icenowy Zheng @ 2018-06-18 18:49 UTC (permalink / raw)
To: jernej.skrabec-gGgVlfcn5nU, Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Rob Herring, David Airlie,
gustavo-THi1TnShQwVAfugRpC6u6w,
maarten.lankhorst-VuQAYsv1563Yd54FQh9/CA, Sean Paul,
Mark Rutland, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, linux-clk, linux-sunxi
在 2018-06-18一的 16:43 +0200，Jernej Škrabec写道：
> Dne ponedeljek, 18. junij 2018 ob 14:58:02 CEST je Jagan Teki
> napisal(a):
> > On Thu, Jun 14, 2018 at 10:59 PM, Jernej Škrabec
> >
> > <jernej.skrabec-gGgVlfcn5nU@public.gmane.org> wrote:
> > > Dne četrtek, 14. junij 2018 ob 19:16:46 CEST je Jagan Teki
> > > napisal(a):
> > > > On Thu, Jun 14, 2018 at 8:04 PM, Jernej Škrabec <jernej.skrabec
> > > > @siol.net>
> > >
> > > wrote:
> > > > > Dne četrtek, 14. junij 2018 ob 09:12:41 CEST je Jagan Teki
> > > > > napisal(a):
> > > > > > On Wed, Jun 13, 2018 at 1:30 AM, Jernej Skrabec
> > > > > > <jernej.skrabec-gGgVlfcn5nU@public.gmane.org>
> > > > >
> > > > > wrote:
> > > > > > > This series adds support for R40 HDMI pipeline. It is a
> > > > > > > bit special
> > > > > > > than other already supported pipelines because it has
> > > > > > > additional
> > > > > > > unit
> > > > > > > called TCON TOP responsible for relationship
> > > > > > > configuration between
> > > > > > > mixers, TCONs and HDMI. Additionally, it has additional
> > > > > > > gates for
> > > > > > > DSI
> > > > > > > and TV TCONs, TV encoder clock settings and pin muxing
> > > > > > > between LCD
> > > > > > > and TV encoders.
> > > > > > >
> > > > > > > However, it seems that TCON TOP will become a norm, since
> > > > > > > newer
> > > > > > > Allwinner SoCs like H6 also have this unit.
> > > > > > >
> > > > > > > I tested different possible configurations:
> > > > > > > - mixer0 <> TCON-TV0 <> HDMI
> > > > > > > - mixer0 <> TCON-TV1 <> HDMI
> > > > > > > - mixer1 <> TCON-TV0 <> HDMI
> > > > > > > - mixer1 <> TCON-TV1 <> HDMI
> > > > > > >
> > > > > > > Please review.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Jernej
> > > > > > >
> > > > > > > Changes from v1:
> > > > > > > - Split DT bindings patch and updated description
> > > > > > > - Split HDMI PHY patch
> > > > > > > - Move header file from TCON TOP patch to dt bindings
> > > > > > > patch
> > > > > > > - Added Rob reviewed-by tag
> > > > > > > - Used clk_hw_register_gate() instead of custom gate
> > > > > > > registration
> > > > > > > code
> > > > > > > - Reworked TCON TOP to be part of of-graph. Because of
> > > > > > > that, a lot
> > > > > > > of
> > > > > > >
> > > > > > > new patches were added.
> > > > > > >
> > > > > > > - Droped mixer index quirk patch
> > > > > > > - Reworked TCON support for TCON TOP
> > > > > > > - Updated commit messages
> > > > > > >
> > > > > > > Jernej Skrabec (27):
> > > > > > > clk: sunxi-ng: r40: Add minimal rate for video PLLs
> > > > > > > clk: sunxi-ng: r40: Allow setting parent rate to
> > > > > > > display related
> > > > > > >
> > > > > > > clocks
> > > > > > >
> > > > > > > clk: sunxi-ng: r40: Export video PLLs
> > > > > > > dt-bindings: display: sunxi-drm: Add TCON TOP
> > > > > > > description
> > > > > > > drm/sun4i: Add TCON TOP driver
> > > > > > > drm/sun4i: Fix releasing node when enumerating enpoints
> > > > > > > drm/sun4i: Split out code for enumerating endpoints in
> > > > > > > output port
> > > > > > > drm/sun4i: Add support for traversing graph with TCON
> > > > > > > TOP
> > > > > > > drm/sun4i: Don't skip TCONs if they don't have channel
> > > > > > > 0
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 TV TCON
> > > > > > > description
> > > > > > > drm/sun4i: tcon: Add support for tcon-top gate
> > > > > > > drm/sun4i: tcon: Generalize engine search algorithm
> > > > > > > drm/sun4i: Don't check for LVDS and RGB when TCON has
> > > > > > > only ch1
> > > > > > > drm/sun4i: Don't check for panel or bridge on TV TCONs
> > > > > > > drm/sun4i: Add support for R40 TV TCON
> > > > > > > dt-bindings: display: sun4i-drm: Add R40 mixer
> > > > > > > compatibles
> > > > > > > drm/sun4i: Add support for R40 mixers
> > > > > > > dt-bindings: display: sun4i-drm: Add description of A64
> > > > > > > HDMI PHY
> > > > > > > drm/sun4i: Enable DW HDMI PHY clock
> > > > > > > drm/sun4i: Don't change clock bits in DW HDMI PHY
> > > > > > > driver
> > > > > > > drm/sun4i: DW HDMI PHY: Add support for second PLL
> > > > > > > drm/sun4i: Add support for second clock parent to DW
> > > > > > > HDMI PHY clk
> > > > > > >
> > > > > > > driver
> > > > > > >
> > > > > > > drm/sun4i: Add support for A64 HDMI PHY
> > > > > > > drm: of: Export drm_crtc_port_mask()
> > > > > > > drm/sun4i: DW HDMI: Expand algorithm for possible crtcs
> > > > > > > ARM: dts: sun8i: r40: Add HDMI pipeline
> > > > > > > ARM: dts: sun8i: r40: Enable HDMI output on BananaPi M2
> > > > > > > Ultra
> > > > > >
> > > > > > Tested whole series on top of linux-next.
> > > > > >
> > > > > > Tested-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> > > > >
> > > > > Thanks!
> > > >
> > > > I've V40 board, which is same as R40. I'm able to detect the
> > > > HDMI but
> > > > seems edid not detecting properly.
> > > >
> > > > [ 0.983007] sun4i-drm display-engine: bound 1100000.mixer
> > > > (ops
> > > > 0xc074a80c) [ 0.999043] sun4i-drm display-engine: bound
> > > > 1200000.mixer
> > > > (ops 0xc074a80c) [ 1.006229] sun4i-drm display-engine: bound
> > > > 1c70000.tcon-top (ops 0xc074e2ac) [ 1.013609] sun4i-drm
> > > > display-engine:
> > > > bound 1c73000.lcd-controller (ops 0xc0747a28)
> > > > [ 1.053988] sun8i-dw-hdmi 1ee0000.hdmi: Detected HDMI TX
> > > > controller
> > > > v1.32a with HDCP (sun8i_dw_hdmi_phy)
> > > > [ 1.063913] sun8i-dw-hdmi 1ee0000.hdmi: registered
> > > > DesignWare HDMI
> > > > I2C bus driver
> > > > [ 1.071683] sun4i-drm display-engine: bound 1ee0000.hdmi
> > > > (ops
> > > > 0xc074a298) [ 1.078484] [drm] Supports vblank timestamp
> > > > caching Rev 2
> > > > (21.10.2013). [ 1.085098] [drm] No driver support for vblank
> > > > timestamp query. [ 1.091055] [drm] Cannot find any crtc or
> > > > sizes
> > > > [ 1.095995] [drm] Initialized sun4i-drm 1.0.0 20150629 for
> > > > display-engine on minor 0
> > >
> > > This seems like DT issue. Can you post somewhere your V40 DTSI
> > > (if it is
> > > different to R40) and board DTS?
> >
> > same dtsi shared between r40 and v40, here is board dts support for
> > HDMI[1]
> >
> > [1] https://paste.ubuntu.com/p/wqVz38BHrM/
>
> This patch looks like exactly the same as mine for BananaPi M2U, so
> there
> should be no issues.
As I know, M2B is designed to be compatible with M2U, so most things
should be the same. The stock firmware even use the same images for
both M2U and M2B.
>
> What about VCC-HDMI? Is powered? Can you measure it to check?
>
> Best regards,
> Jernej
>
>
>
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 201+ messages in thread