From: Michael Riesch <hidden> Date: 2021-08-23 12:39:29
Hi all,
The following error messages appear on my RK3568 EVB1 board during boot:
rockchip_clk_register_muxgrf: regmap not available
rockchip_clk_register_branches: failed to register clock clk_ddr1x: -524
These can be fixed by providing the missing rockchip,grf property to the
device tree (similar to other Rockchip SoCs, such as the RK3399).
However, the rockchip,rk3568-cru bindings do not specify a property of that
name. Am I missing something or should this property be added to the bindings?
Best regards,
Michael
Michael Riesch (1):
arm64: dts: rockchip: add missing rockchip,grf property to rk356x
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 +
1 file changed, 1 insertion(+)
--
2.17.1
From: Michael Riesch <hidden> Date: 2021-08-23 12:39:32
This commit fixes the error messages
rockchip_clk_register_muxgrf: regmap not available
rockchip_clk_register_branches: failed to register clock clk_ddr1x: -524
during boot by providing the missing rockchip,grf property.
Signed-off-by: Michael Riesch <redacted>
---
arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 +
1 file changed, 1 insertion(+)
From: Peter Geis <hidden> Date: 2021-08-23 13:12:24
On Mon, Aug 23, 2021 at 8:39 AM Michael Riesch
[off-list ref] wrote:
This commit fixes the error messages
rockchip_clk_register_muxgrf: regmap not available
rockchip_clk_register_branches: failed to register clock clk_ddr1x: -524
during boot by providing the missing rockchip,grf property.
Good Morning,
This was fixed by commit: 6fffe52fb336 clk: rockchip: drop GRF
dependency for rk3328/rk3036 pll types
which was merged in -next. I don't believe it's going to be backported
to 5.14 due to 5.14 not being able to fully boot.
Very Respectfully,
Peter Geis
From: Michael Riesch <hidden> Date: 2021-08-23 13:39:28
Hi Peter,
On 8/23/21 3:12 PM, Peter Geis wrote:
On Mon, Aug 23, 2021 at 8:39 AM Michael Riesch
[off-list ref] wrote:
quoted
This commit fixes the error messages
rockchip_clk_register_muxgrf: regmap not available
rockchip_clk_register_branches: failed to register clock clk_ddr1x: -524
during boot by providing the missing rockchip,grf property.
Good Morning,
This was fixed by commit: 6fffe52fb336 clk: rockchip: drop GRF
dependency for rk3328/rk3036 pll types
which was merged in -next. I don't believe it's going to be backported
to 5.14 due to 5.14 not being able to fully boot.
Unfortunately not, I am afraid. I am working on Heiko's current -next
and the commit you mentioned is present. Nevertheless I got these error
messages.
They can be traced down to "rockchip_clk_register_muxgrf", which fails
as the passed argument regmap is invalid due to the missing device tree
property. The clock "clk_ddr1x" is added in clk-rk3568.c as "MUXGRF",
which leads me to believe that the grf property is actually required.
Best regards,
Michael
From: Peter Geis <hidden> Date: 2021-08-23 13:51:49
On Mon, Aug 23, 2021 at 9:39 AM Michael Riesch
[off-list ref] wrote:
Hi Peter,
On 8/23/21 3:12 PM, Peter Geis wrote:
quoted
On Mon, Aug 23, 2021 at 8:39 AM Michael Riesch
[off-list ref] wrote:
quoted
This commit fixes the error messages
rockchip_clk_register_muxgrf: regmap not available
rockchip_clk_register_branches: failed to register clock clk_ddr1x: -524
during boot by providing the missing rockchip,grf property.
Good Morning,
This was fixed by commit: 6fffe52fb336 clk: rockchip: drop GRF
dependency for rk3328/rk3036 pll types
which was merged in -next. I don't believe it's going to be backported
to 5.14 due to 5.14 not being able to fully boot.
Unfortunately not, I am afraid. I am working on Heiko's current -next
and the commit you mentioned is present. Nevertheless I got these error
messages.
They can be traced down to "rockchip_clk_register_muxgrf", which fails
as the passed argument regmap is invalid due to the missing device tree
property. The clock "clk_ddr1x" is added in clk-rk3568.c as "MUXGRF",
which leads me to believe that the grf property is actually required.
Ah, yes it seems you are correct.
I had inadvertently fixed this a while ago in my own tree.
Confirmed without the GRF ddr1x clk doesn't register.
Tested-by: Peter Geis <redacted>
On a related note, are you planning on working on the DVFS driver,
since it will be the only consumer of this clock?
On Mon, 23 Aug 2021 14:39:10 +0200, Michael Riesch wrote:
The following error messages appear on my RK3568 EVB1 board during boot:
rockchip_clk_register_muxgrf: regmap not available
rockchip_clk_register_branches: failed to register clock clk_ddr1x: -524
These can be fixed by providing the missing rockchip,grf property to the
device tree (similar to other Rockchip SoCs, such as the RK3399).
[...]
From: Michael Riesch <hidden> Date: 2021-08-25 08:19:15
Hi Peter,
On 8/23/21 3:51 PM, Peter Geis wrote:
On Mon, Aug 23, 2021 at 9:39 AM Michael Riesch
[off-list ref] wrote:
quoted
Hi Peter,
On 8/23/21 3:12 PM, Peter Geis wrote:
quoted
On Mon, Aug 23, 2021 at 8:39 AM Michael Riesch
[off-list ref] wrote:
quoted
This commit fixes the error messages
rockchip_clk_register_muxgrf: regmap not available
rockchip_clk_register_branches: failed to register clock clk_ddr1x: -524
during boot by providing the missing rockchip,grf property.
Good Morning,
This was fixed by commit: 6fffe52fb336 clk: rockchip: drop GRF
dependency for rk3328/rk3036 pll types
which was merged in -next. I don't believe it's going to be backported
to 5.14 due to 5.14 not being able to fully boot.
Unfortunately not, I am afraid. I am working on Heiko's current -next
and the commit you mentioned is present. Nevertheless I got these error
messages.
They can be traced down to "rockchip_clk_register_muxgrf", which fails
as the passed argument regmap is invalid due to the missing device tree
property. The clock "clk_ddr1x" is added in clk-rk3568.c as "MUXGRF",
which leads me to believe that the grf property is actually required.
Ah, yes it seems you are correct.
I had inadvertently fixed this a while ago in my own tree.
Confirmed without the GRF ddr1x clk doesn't register.
Tested-by: Peter Geis <redacted>
Thanks for testing/your T-B!
On a related note, are you planning on working on the DVFS driver,
since it will be the only consumer of this clock?
Until now I was not aware of this, so it is not on my plan. But thanks
for pointing it out, it is definitely something we would like to see
(and maybe could help to implement).
Best regards,
Michael