It is used to be believed that the A64 HDMI PHY has the PLL-VIDEO mux which is introduced in R40, because A64 has two PLL-VIDEOs. However, experiments show that the mux is not present in A64, so the compatible string of dual-PLL-input HDMI PHY clock must be changed to use R40 in it rather than A64.
This patchset does this change.
Because the compatible string is introduced in 4.19, this patchset should be applied to 4.19 during RC stage, otherwise this error will exist forever for DT compatibility.
Icenowy Zheng (3): dt-bindings: change the A64 HDMI PHY binding to R40 drm/sun4i: change A64 HDMI PHY binding to R40 ARM: sun8i: dts: r40: drop A64 fallback compatible string of HDMI PHY
.../devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 +++--- arch/arm/boot/dts/sun8i-r40.dtsi | 3 +-- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 6 +++--- 3 files changed, 7 insertions(+), 8 deletions(-)
By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux introduced in R40, although it has two PLL-VIDEOs.
Change the A64 HDMI PHY binding to R40 one.
This binding is introduced in v4.19, which is still in RC stage, so we have change to fix it.
Signed-off-by: Icenowy Zheng icenowy@aosc.io --- .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index f8773ecb7525..de6814a5aba3 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -103,7 +103,7 @@ Required properties: - compatible: value must be one of: * allwinner,sun8i-a83t-hdmi-phy * allwinner,sun8i-h3-hdmi-phy - * allwinner,sun50i-a64-hdmi-phy + * allwinner,sun8i-r40-hdmi-phy - reg: base address and size of memory-mapped region - clocks: phandles to the clocks feeding the HDMI PHY * bus: the HDMI PHY interface clock @@ -112,9 +112,9 @@ Required properties: - resets: phandle to the reset controller driving the PHY - reset-names: must be "phy"
-H3 and A64 HDMI PHY require additional clocks: +H3 and R40 HDMI PHY require additional clocks: - pll-0: parent of phy clock - - pll-1: second possible phy clock parent (A64 only) + - pll-1: second possible phy clock parent (R40 only)
TV Encoder ----------
On Mon, Sep 03, 2018 at 09:34:32PM +0800, Icenowy Zheng wrote:
By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux introduced in R40, although it has two PLL-VIDEOs.
Change the A64 HDMI PHY binding to R40 one.
This binding is introduced in v4.19, which is still in RC stage, so we have change to fix it.
Signed-off-by: Icenowy Zheng icenowy@aosc.io
That doesn't make much sense. The A64 doesn't have any particular reason to behave like the R40, and the R40 can definitely use a different compatible if it has a different behaviour. But I don't see *why* the A64 not behaving like the R40 is a justification to remove the A64 compatible. Especially when the R40 was released later.
Add a new compatible, and leave the A64 compatible alone.
Maxime
于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard maxime.ripard@bootlin.com 写到:
On Mon, Sep 03, 2018 at 09:34:32PM +0800, Icenowy Zheng wrote:
By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux introduced in R40, although it has two PLL-VIDEOs.
Change the A64 HDMI PHY binding to R40 one.
This binding is introduced in v4.19, which is still in RC stage, so
we
have change to fix it.
Signed-off-by: Icenowy Zheng icenowy@aosc.io
That doesn't make much sense. The A64 doesn't have any particular reason to behave like the R40, and the R40 can definitely use a different compatible if it has a different behaviour. But I don't see *why* the A64 not behaving like the R40 is a justification to remove the A64 compatible. Especially when the R40 was released later.
Add a new compatible, and leave the A64 compatible alone.
But the behavior of A64 compatible will change from double PLL to single PLL, because the A64 HDMI PHY is proven to have no double PLL.
Should I then change the A64 compatible behavior and import R40 compatible at the same time?
In addition maybe I can just drop A64 compatible, and let A64 use H3 one. Then I will add a R40 compatible to catch dual PLL behavior.
Maxime
On Wed, Sep 05, 2018 at 03:46:41PM +0800, Icenowy Zheng wrote:
于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard maxime.ripard@bootlin.com 写到:
On Mon, Sep 03, 2018 at 09:34:32PM +0800, Icenowy Zheng wrote:
By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux introduced in R40, although it has two PLL-VIDEOs.
Change the A64 HDMI PHY binding to R40 one.
This binding is introduced in v4.19, which is still in RC stage, so
we
have change to fix it.
Signed-off-by: Icenowy Zheng icenowy@aosc.io
That doesn't make much sense. The A64 doesn't have any particular reason to behave like the R40, and the R40 can definitely use a different compatible if it has a different behaviour. But I don't see *why* the A64 not behaving like the R40 is a justification to remove the A64 compatible. Especially when the R40 was released later.
Add a new compatible, and leave the A64 compatible alone.
But the behavior of A64 compatible will change from double PLL to single PLL, because the A64 HDMI PHY is proven to have no double PLL.
Should I then change the A64 compatible behavior and import R40 compatible at the same time?
I don't see why you should do both at the same time. Fix the A64, and add the support for the R40, those are two orthogonal changes.
In addition maybe I can just drop A64 compatible, and let A64 use H3 one.
No, that break the backward compatibility.
Maxime
于 2018年9月5日 GMT+08:00 下午3:56:01, Maxime Ripard maxime.ripard@bootlin.com 写到:
On Wed, Sep 05, 2018 at 03:46:41PM +0800, Icenowy Zheng wrote:
于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard
On Mon, Sep 03, 2018 at 09:34:32PM +0800, Icenowy Zheng wrote:
By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux introduced in R40, although it has two PLL-VIDEOs.
Change the A64 HDMI PHY binding to R40 one.
This binding is introduced in v4.19, which is still in RC stage,
so
we
have change to fix it.
Signed-off-by: Icenowy Zheng icenowy@aosc.io
That doesn't make much sense. The A64 doesn't have any particular reason to behave like the R40, and the R40 can definitely use a different compatible if it has a different behaviour. But I don't
see
*why* the A64 not behaving like the R40 is a justification to remove the A64 compatible. Especially when the R40 was released later.
Add a new compatible, and leave the A64 compatible alone.
But the behavior of A64 compatible will change from double PLL to single PLL, because the A64 HDMI PHY is proven to have no double PLL.
Should I then change the A64 compatible behavior and import R40 compatible at the same time?
I don't see why you should do both at the same time. Fix the A64, and add the support for the R40, those are two orthogonal changes.
Then how to deal with double PLL support? Make them temporarily dead during 4.19?
In addition maybe I can just drop A64 compatible, and let A64 use H3 one.
No, that break the backward compatibility.
As I said A64 compatible is just introduced in 4.19-rc.
So if we finish before 4.19.0 we break nothing.
Maxime
On Wed, Sep 05, 2018 at 04:05:18PM +0800, Icenowy Zheng wrote:
于 2018年9月5日 GMT+08:00 下午3:56:01, Maxime Ripard maxime.ripard@bootlin.com 写到:
On Wed, Sep 05, 2018 at 03:46:41PM +0800, Icenowy Zheng wrote:
于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard
On Mon, Sep 03, 2018 at 09:34:32PM +0800, Icenowy Zheng wrote:
By experiment, the A64 HDMi PHY doesn't support the PLL-VIDEO mux introduced in R40, although it has two PLL-VIDEOs.
Change the A64 HDMI PHY binding to R40 one.
This binding is introduced in v4.19, which is still in RC stage,
so
we
have change to fix it.
Signed-off-by: Icenowy Zheng icenowy@aosc.io
That doesn't make much sense. The A64 doesn't have any particular reason to behave like the R40, and the R40 can definitely use a different compatible if it has a different behaviour. But I don't
see
*why* the A64 not behaving like the R40 is a justification to remove the A64 compatible. Especially when the R40 was released later.
Add a new compatible, and leave the A64 compatible alone.
But the behavior of A64 compatible will change from double PLL to single PLL, because the A64 HDMI PHY is proven to have no double PLL.
Should I then change the A64 compatible behavior and import R40 compatible at the same time?
I don't see why you should do both at the same time. Fix the A64, and add the support for the R40, those are two orthogonal changes.
Then how to deal with double PLL support? Make them temporarily dead during 4.19?
Well, if the PHY doesn't use two PLL, don't use it, ever. Why does it have to be temporary?
The Allwinner A64 SoC is proven to have no PLL-VIDEO mux in the HDMI PHY clock, although it has two PLL-VIDEOs. The R40 SoC has this mux.
Change the binding compatible string from sun50i-a64 to sun8i-r40, and let A64 to use H3 compatible string.
The compatible string is introduced in v4.19, and during the RC stage we can still change it.
Signed-off-by: Icenowy Zheng icenowy@aosc.io --- drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c index 82502b351aec..744a8a2a15c0 100644 --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c @@ -396,7 +396,7 @@ static struct regmap_config sun8i_hdmi_phy_regmap_config = { .name = "phy" };
-static const struct sun8i_hdmi_phy_variant sun50i_a64_hdmi_phy = { +static const struct sun8i_hdmi_phy_variant sun8i_r40_hdmi_phy = { .has_phy_clk = true, .has_second_pll = true, .phy_init = &sun8i_hdmi_phy_init_h3, @@ -419,8 +419,8 @@ 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-r40-hdmi-phy", + .data = &sun8i_r40_hdmi_phy, }, { .compatible = "allwinner,sun8i-a83t-hdmi-phy",
The A64 HDMI PHY is proven to have no PLL-VIDEO mux, thus it's not compatible with the R40 one.
Drop the A64 fallback compatible string in R40 device tree.
Signed-off-by: Icenowy Zheng icenowy@aosc.io --- arch/arm/boot/dts/sun8i-r40.dtsi | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi b/arch/arm/boot/dts/sun8i-r40.dtsi index ffd9f00f74a4..5f547c161baf 100644 --- a/arch/arm/boot/dts/sun8i-r40.dtsi +++ b/arch/arm/boot/dts/sun8i-r40.dtsi @@ -800,8 +800,7 @@ };
hdmi_phy: hdmi-phy@1ef0000 { - compatible = "allwinner,sun8i-r40-hdmi-phy", - "allwinner,sun50i-a64-hdmi-phy"; + compatible = "allwinner,sun8i-r40-hdmi-phy"; reg = <0x01ef0000 0x10000>; clocks = <&ccu CLK_BUS_HDMI1>, <&ccu CLK_HDMI_SLOW>, <&ccu 7>, <&ccu 16>;
dri-devel@lists.freedesktop.org
-
Icenowy Zheng -
Maxime Ripard