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(-)
--
2.18.0
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 <[email protected]>
---
.../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
----------
--
2.18.0
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 <[email protected]>
---
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",
--
2.18.0
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 <[email protected]>
---
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>;
--
2.18.0
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 <[email protected]>
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
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard <[email protected]> 写到:
>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 <[email protected]>
>
>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 <[email protected]> 写到:
> >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 <[email protected]>
> >
> >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
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
于 2018年9月5日 GMT+08:00 下午3:56:01, Maxime Ripard <[email protected]> 写到:
>On Wed, Sep 05, 2018 at 03:46:41PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard
><[email protected]> 写到:
>> >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 <[email protected]>
>> >
>> >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 <[email protected]> 写到:
> >On Wed, Sep 05, 2018 at 03:46:41PM +0800, Icenowy Zheng wrote:
> >>
> >>
> >> 于 2018年9月5日 GMT+08:00 下午3:14:35, Maxime Ripard
> ><[email protected]> 写到:
> >> >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 <[email protected]>
> >> >
> >> >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?
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com