| Message ID | 20210823123911.12095-2-michael.riesch@wolfvision.net |
|---|---|
| State | Accepted |
| Commit | 95ad4dbe5f43bf67036775df56c848aa8ffea8e2 |
| Headers | show |
| Series | [1/1] arm64: dts: rockchip: add missing rockchip,grf property to rk356x | expand |
On Mon, Aug 23, 2021 at 9:39 AM Michael Riesch <michael.riesch@wolfvision.net> wrote: > > Hi Peter, > > On 8/23/21 3:12 PM, Peter Geis wrote: > > On Mon, Aug 23, 2021 at 8:39 AM Michael Riesch > > <michael.riesch@wolfvision.net> 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. > > 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 <pgwipeout@gmail.com> On a related note, are you planning on working on the DVFS driver, since it will be the only consumer of this clock? > > Best regards, > Michael > > > > > Very Respectfully, > > Peter Geis > > > >> > >> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> > >> --- > >> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > >> index 23949e79d8ce..0a1d07c96b2e 100644 > >> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi > >> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > >> @@ -233,6 +233,7 @@ > >> #reset-cells = <1>; > >> assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>; > >> assigned-clock-rates = <1200000000>, <200000000>; > >> + rockchip,grf = <&grf>; > >> }; > >> > >> i2c0: i2c@fdd40000 { > >> -- > >> 2.17.1 > >>
Hi Peter, On 8/23/21 3:51 PM, Peter Geis wrote: > On Mon, Aug 23, 2021 at 9:39 AM Michael Riesch > <michael.riesch@wolfvision.net> wrote: >> >> Hi Peter, >> >> On 8/23/21 3:12 PM, Peter Geis wrote: >>> On Mon, Aug 23, 2021 at 8:39 AM Michael Riesch >>> <michael.riesch@wolfvision.net> 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. >> >> 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 <pgwipeout@gmail.com> 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 > >> >> Best regards, >> Michael >> >>> >>> Very Respectfully, >>> Peter Geis >>> >>>> >>>> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> >>>> --- >>>> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi >>>> index 23949e79d8ce..0a1d07c96b2e 100644 >>>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi >>>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi >>>> @@ -233,6 +233,7 @@ >>>> #reset-cells = <1>; >>>> assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>; >>>> assigned-clock-rates = <1200000000>, <200000000>; >>>> + rockchip,grf = <&grf>; >>>> }; >>>> >>>> i2c0: i2c@fdd40000 { >>>> -- >>>> 2.17.1 >>>>
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi index 23949e79d8ce..0a1d07c96b2e 100644 --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi @@ -233,6 +233,7 @@ #reset-cells = <1>; assigned-clocks = <&cru PLL_GPLL>, <&pmucru PLL_PPLL>; assigned-clock-rates = <1200000000>, <200000000>; + rockchip,grf = <&grf>; }; i2c0: i2c@fdd40000 {
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 <michael.riesch@wolfvision.net> --- arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 + 1 file changed, 1 insertion(+)