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

Jagan Teki jagan at amarulasolutions.com
Tue Mar 31 07:59:23 CEST 2020

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.


More information about the U-Boot mailing list