Hi Jagan,
On 2020/3/31 下午1:59, Jagan Teki wrote:
On Tue, Mar 31, 2020 at 1:06 AM Mark Kettenis <mark.kettenis@xxxxxxxxx> wrote:
From: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx>
Cc: sunil@xxxxxxxxxxxxxxxxxxxx, u-boot@xxxxxxxxxxxxx,
linux-rockchip@xxxxxxxxxxxxxxxxxxx, linux-amarula@xxxxxxxxxxxxxxxxxxxx,
Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx>
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.
I agree with Mark for not touch the dts first. I don't know the detail
of display driver but:
- The rk3399 driver use to work without touch dts from kernel;
- the clock driver have a rk3399_vop_set_clk() which does not depends on
dts.
Thanks,
- Kever
Jagan.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-rockchip
