[U-Boot] [patch u-boot git arm/next] davinci: display correct clock info

[Jean-Christophe PLAGNIOL-VILLARD]

On 17:13 Wed 29 Apr     , David Brownell wrote:
> On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 15:38 Wed 29 Apr     , David Brownell wrote:
> > > From: David Brownell <dbrownell at users.sourceforge.net>
> > > 
> > > Make the DaVinci clock display code work on the dm355 too ... there
> > > are pre- and post- dividers on its PLLs, which most other DaVinci
> > > processors don't use; and it uses different PLL dividers.  Stubbed
> > > in support for the DM6467 too.  Verified on dm355 and dm6446.
> > > 
> > > Signed-off-by: David Brownell <dbrownell at users.sourceforge.net>
> > > ---
> > > This should move to cpu/arm926ejs/davinci (cpuinfo.c?) someday,
> > > like the other SoC-specific code.  For another patch.
> >
> > good idea
> > 
> > cpu.c will be better
> 
> I was thinking of using CONFIG_DISPLAY_CPUINFO hooks for that,
> and those seem to be in cpuinfo.c files.  (Someday, when time
> allows.)
> 
> 
> > btw a clock design as done for at91 & avr32 will be nice too
> 
> It's missing from at91rm9200 ... ;)
sure but in preparaton as the at91rm9200 will be merge with the AT91 soon
> 
> Those seem to be useful if U-Boot is the first stage boot
> loader, running out of NOR flash and needing to do lots of
> low level setup:  configure PLLs, clock divisors, memory
> timings, start DRAM, and so on.
> 
> But most DaVinci boards boot from NAND flash nowadays, making
> U-boot be a third stage loader with no lowlevel init.  So
> it doesn't need such code ... but if it did, it would touch
> the PLL controllers in very different ways (modifying the
> registers and handshaking, not just reading like this).
ok the calc clock, I've more in mind the get_xxx_clk_rate() api
> 
> 
> > > +/* offsets from PLL controller base */
> > > +#define PLLC_PLLCTL	0x100
> > > +#define PLLC_PLLM	0x110
> > > +#define PLLC_PREDIV	0x114
> > > +#define PLLC_PLLDIV1	0x118
> > > +#define PLLC_PLLDIV2	0x11c
> > > +#define PLLC_PLLDIV3	0x120
> > > +#define PLLC_POSTDIV	0x128
> > > +#define PLLC_BPDIV	0x12c
> > > +#define PLLC_PLLDIV4	0x160
> > > +#define PLLC_PLLDIV5	0x164
> > > +#define PLLC_PLLDIV6	0x168
> > > +#define PLLC_PLLDIV8	0x170
> > > +#define PLLC_PLLDIV9	0x174
> >
> > who will init the PLL?
> > can we detect it if they are already init?
> 
> PLL setup is part of lowlevel init ... usually it's
> done by the second stage boot loader (UBL) if this
> is booting from anything except NOR flash.  For NOR
> boot that's now done in cpu/.../lowlevel_init.S code.
> 
> By the time this code is called, that's been done a
> long time ago ... we're running out of DRAM, which
> can't work without active PLLs.  (The oscillator is
> from 20-30 MHz, the DRAM clock must be 125 MHz and
> up, QED.)
my idea is more this
the lowlovel will init the pll (lowlevel_init.S or other stage bootloader)
so instead of hardcoding the PPLDIV read it in the register
and then calculate the clock rate and it need it set the other non used clock
depending on the IP used by u-boot (at runtime)

Best Regards,
J.