Hi Marek,
On Fri, Apr 20, 2012 at 8:23 AM, Marek Vasut <ma...@denx.de> wrote:
> Dear Ilya Averyanov,
>
>> 2012/4/20 Marek Vasut <ma...@denx.de>
>>
>> > Dear Gabriel Huau,
>> >
>> > > On Thu, Apr 19, 2012 at 10:08:47PM +0200, Marek Vasut wrote:
>> > > > Dear Gabriel Huau,
>> > > >
>> > > > > ---
>> > > > >
>> > > > > + /* some delay between MPLL and UPLL */
>> > > > > + pll_delay(500000);
>> > > >
>> > > > You use udelay() below, do you need pll_delay() at all?
>> > >
>> > > Yes, because initialisation of PLL is done before timer_init(), so we
>> > > can't use udelay().
>> >
>> > Maybe fix the timer driver?
>>
>> How fix timer driver if arch_cpu_init(void) call befor timer_init in
>> \arch\arm\lib\board.c:227 init_fnc_t *init_sequence[] = {
>
> Where did you get such a weird path? \arch\arm... ?
>
> btw you can always check some bit, if the timer is enabled, behave one way,
> otherwise, behave other way.
There is plenty of room in gd->flags - Pick a bit in the high-order 16-bits
It will be clear at startup and when you initialise the timer, you can set
the bit. udelay() can do a simple test on the bit and call the appropriate
function
Regards,
Graeme
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
