[v2,1/4] arm64: dts: rk3399-u-boot: Delete vop assigned-clocks/rates

Linux supporting assigned-clocks for VOP on rk3399 by assuming
U-Boot not initializing it on this linux commit:

commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")

There is no specific need to initialize these assigned clock
in U-Boot as video drivers still work with default aclk and ?
hclk values. So, these clocks are simply not supported by rk3399
clock driver.

But, during stdio probe of vidconsole, the device probe
will try to check whether the assigned clocks on that video
console node is initialized or not? and return error if not.

So, delete these property via -u-boot dtsi as there is
no specific need in U-Boot.

Signed-off-by: Jagan Teki <jagan at amarulasolutions.com>
---
Changes for v2:
- none

 arch/arm/dts/rk3399-u-boot.dtsi | 4 ++++
 1 file changed, 4 insertions(+)

> From: Jagan Teki <jagan at amarulasolutions.com>
> Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
>         linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
>         Jagan Teki <jagan at amarulasolutions.com>
> Date: Mon, 30 Mar 2020 23:46:10 +0530
> Content-Type: text/plain; charset=UTF-8
> 
> Linux supporting assigned-clocks for VOP on rk3399 by assuming
> U-Boot not initializing it on this linux commit:
> 
> commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> 
> There is no specific need to initialize these assigned clock
> in U-Boot as video drivers still work with default aclk and ?
> hclk values. So, these clocks are simply not supported by rk3399
> clock driver.
> 
> But, during stdio probe of vidconsole, the device probe
> will try to check whether the assigned clocks on that video
> console node is initialized or not? and return error if not.
> 
> So, delete these property via -u-boot dtsi as there is
> no specific need in U-Boot.

Deleting these properties isn't very helpful as it means the U-Boot
device tree can no longer be used by the kernel.  Isn't it a better
idea to implement these clocks as stubs in the u-boot clock driver?

> Signed-off-by: Jagan Teki <jagan at amarulasolutions.com>
> ---
> Changes for v2:
> - none
> 
>  arch/arm/dts/rk3399-u-boot.dtsi | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8b857ccfc7..b846f9cde7 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -99,9 +99,13 @@
>  };
>  
>  &vopb {
> +	/delete-property/ assigned-clocks;
> +	/delete-property/ assigned-clock-rates;
>  	u-boot,dm-pre-reloc;
>  };
>  
>  &vopl {
> +	/delete-property/ assigned-clocks;
> +	/delete-property/ assigned-clock-rates;
>  	u-boot,dm-pre-reloc;
>  };
> -- 
> 2.17.1
> 
>

On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Jagan Teki <jagan at amarulasolutions.com>
> > Cc: sunil at amarulasolutions.com, u-boot at lists.denx.de,
> >         linux-rockchip at lists.infradead.org, linux-amarula at amarulasolutions.com,
> >         Jagan Teki <jagan at amarulasolutions.com>
> > Date: Mon, 30 Mar 2020 23:46:10 +0530
> > Content-Type: text/plain; charset=UTF-8
> >
> > Linux supporting assigned-clocks for VOP on rk3399 by assuming
> > U-Boot not initializing it on this linux commit:
> >
> > commit <617f4472bdd3> ("arm64: dts: rockchip: init rk3399 vop clock rates")
> >
> > There is no specific need to initialize these assigned clock
> > in U-Boot as video drivers still work with default aclk and
> > hclk values. So, these clocks are simply not supported by rk3399
> > clock driver.
> >
> > But, during stdio probe of vidconsole, the device probe
> > will try to check whether the assigned clocks on that video
> > console node is initialized or not? and return error if not.
> >
> > So, delete these property via -u-boot dtsi as there is
> > no specific need in U-Boot.
>
> Deleting these properties isn't very helpful as it means the U-Boot
> device tree can no longer be used by the kernel.  Isn't it a better
> idea to implement these clocks as stubs in the u-boot clock driver?

I did try this before sorting out these changes, seems like it
requires a bit more tweaking the clock wrt display code. I really
didn't see any use case as of now for just to print u-boot log on
display out, and more over this support has been broken since from
releases. so bypassing these nodes can be a solutions for now.

Jagan.