Dear Stefan Roese,
In message 201010071327.40328.sr@denx.de you wrote:
The idea of implementing the watchdog_reset call in this function comes from the original implementation in the PPC4xx UART driver. As the ns166550 driver is now used on PPC4xx, this is missing right now and results in resets upon long outputs (e.g. printenv, fdt print) on lwmon5. The "old" PPC4xx UART driver did call udelay() in the putc() function. This implicitly called WATCHDOG_RESET(). I didn't want to add this udelay to ns16550, since this would lead to code increase for platforms not using this watchdog.
Code size increase, and slow down.
Back to the problem: How about moving the watchdog_reset call to serial_puts() in common/serial.c? Or do you have another (better) idea in mind?
Are you really sure this is the right place, i. e. this is where the problem happens?
I doubt that.
lwmon5 which has this nasty 100 ms watchdog (actually 80 ms including allowable tolerances, IIRC) is running at 115bps.
In theory, it would take a string of more than 900 characters for puts() to exceeding this delay, but all strings ever printed in U-Boot are way shorter.
That's why I ask again: are you sure it's puts() that is causing such long delays? Or should the watchdog triggering better happen somewhere else?
If you want to go with the triggering in serial_puts(), you probably either want to trigger unconditionally, before or after each call to puts(). The counter based approach makes no sense to me. If you are lucky it does not show any effect, and if you have bad luck it interferes with the WD_PERIOD / WD_MAX_RATE settings on this board.
Please keep in mind that on this specific board we have both upper and lower bounds for the WD trigger interval.
Best regards,
Wolfgang Denk