On 16/05/2018 11:04, Marek Vasut wrote:
On 05/16/2018 11:00 AM, Jean-Jacques Hiblot wrote:
On 16/05/2018 00:13, Marek Vasut wrote:
On 05/15/2018 06:10 PM, Jean-Jacques Hiblot wrote:
Hi Marek,
On 04/05/2018 21:06, Marek Vasut wrote:
Shouldnt the driver turn this on?
AFAIK there is no clock driver for the OMAP. So we have to do it
before
the driver is probed.
Maybe it's time to implement it instead of piling up those hacks ?
I was thinking along the same lines at some point but then I realized
that it will make the SPL really big. And we are already tight on some
platforms like am335x.
But this is not only SPL , right ? And yes, for SPL you might need to
poke registers or something.
IMHO having 2 different ways to enable the clocks in SPL and in u-boot
is an not improvement over the current situation.
In any case, This is a subject that can be discussed.
Do you have a better idea ?
I would keep it as it is today.
After studying the clock management in Linux, I believe that
implementing the clock drivers in u-boot won't be an easy task and
moreover won't make things much cleaner.
The way clocks are handled in Linux for the omap platforms is not
completely standard. There are a lot of clocks that are handled by the
clock framework (pll, mux, some gates, ...) but most of the clock gating
for peripherals is handled the HWMOD subsystem which automatically
enables/disables the clocks of the peripherals. Parameters for this
subsystem are hard-coded in platform code (in
arch/arm/mach-omap2/omap-hwmod_xxx_data.c) not in the DTS. It also
handle clock and power domains.
HWMOD is probably going to go away some day, I'm not sure that we want
to implement it in u-boot. Until hwmod has completely replaced by more
generic frameworks, I would stick to platform code to enable clocks in
u-boot.
But if this keeps going on, eventually we will regress to where we were
years ago -- having huge platform specific list of registers to poke to
set a platform up and that'd be it ?
For omap clocks that would be status quo but the rest is moving toward DM
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
