[U-Boot] [PATCH V2] arm: timer and interrupt init rework

[Jean-Christophe PLAGNIOL-VILLARD]

> Also, I do not see why we need to implement such a critical change.
> 
> If I understand you corrctly, your argument goes that board_init()
> needs delays (like udelay()), delays need timers, and timers need
> interrupts, so we must initialize first interrupts, then timers, and
> only then we can run board_init()?  Is this your argument?

First it you wish to do delay before the timer is ready you will have
to do loop delay which is cpu speed dependent so the code is not
maintainable at the end
> 
> But the I ask why udelay() would need  timers  and  interrupts?  This
> does  not fit into the design philosophy of U-Boot, which attempts to
> bring up a board at least to a state where  we  have  serial  console
> output  with  as  little as possible requirements. Your change breaks
> this, because now we have to initialize timers and interrupts  (which
> are  not  exactly  a  trivial thing to set up or debug if they aren't
> working correctly) BEFORE we have a console  output.
On ARM we have two kind of "serial" port the physical one which need init
to be used before and the DCC which can be used at the start of the CPU.
So to debug the timer and earlier init you can use this one.

My changes does not break it as precedently the timer was init by
interrupts_init
the only change is that the board_init will be done after the timer
> [I  ignore  the
> case  of CONFIG_USE_IRQ here, because only 4 boards actually use this
> feature, and they could probably be changed to do without, too.]
IIRC as least the S3C must use interrupt for the timer
> 
> So while I really appreciate your attempts to clean up the timer code
> on ARM, the resulting consequences are expensive, and I  am  not  yet
> convincet  the  advantages  of  the  new  code  are  bigger than this
> disadvantage, and especially I am not convinced  thatthis  is  really
> necessary and unavoidable.
boards actually init the timer themself in thee board_init to have a
correct delay
> 
> Can we not do delays without interrupts?
no not on all soc
> And do  we  need  full-blown timer services for delays?
Yes as we need to init the timer which is in nearly all case soc dependent
> [Keep in mind that a delay is usually used
> to  implement  a timeout in the error branch; that means, it does not
> matter if it has not 10e-6 precision or better.]
not only
it's use for slow clock, for chip reset timing etc...
but the precision is just that if you need to wait 10us you will not wait less
and if you want to wait 100ms you will not have to wait 1s
an other example for spi transfer you will have to use some delay more you
timer is precise more you transfert will be work at higher rate
it's the same for nand etc...

Best Regards,
J.