[U-Boot] [PATCH 4/8] Add a poll function to monitor events

[Wolfgang Denk]

Dear Simon Glass,

In message <CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6WQ4CDOb0zQMgi7XwGwWBQ at mail.gmail.com> you wrote:
> 
> >    If anything like this gets implemented, it has to be done in a way
> >    that will be general enough to be useful to others as well.
> 
> Yes. It isn't really clear how this sort of thing should be done, but
> creating a board polling function seems like a reasonable idea. It's
> then just a question of when to call it. Since there is no particular
> idle or event loop in U-Boot, perhaps we need to create one, and the
> console code is probably the only sensible place since it is waiting
> for user input.

No, using the console driver for such a hook is not sensible at all.

Do we really have to re-invent the wheel each time we need one?

If we need a periodic service, then this should be obviously (at least
this seems obvious to me) be bound to the timer services.  On PPC, we
could for example simply hook it in the timer interrupt.

Also, this should not be considered as somethin board specific as the
name "board polling function" might suggest.  What is being discussed
here is not more and not less than support for periodic, asynchronous
services.  So let's call it that, so everybody understand what it's
about.

> I am not sure about the general issue. Obviously some sort of
> background activity is going on in the chip all the time, and
> monitoring is sometimes necessary. I am not sure about the best
> approach for this.

I agree about the "sometimes necessary".  In this specific case, I
doubt is this is one of these "some" cases.  But I asked this before.

> By monitoring temperature we can be sure that the system does not
> overheat - it does depend on the hardware of course (power output,
> heatsinks) but it can happen very quickly, certainly within a few 10s
> of seconds.

Is this some theoretical consideration, or does it refer to the actual
state of a specific piece of hardware?

Assume we have such a system - how would it be going to be used?
Example:

	- power on
	- U-Boot enters (either directly or as a result of some boot
	  error or similar) the interactive command line interface and
	  waits for input from the user
	- temperature monitoring detects overheating
	- system powers down

How would one recover from that?

Would it not make much more sense to bring up the system in such a
mode of operation that no overheating will happen?

> > This needs a lot of additional thought, and major changes to the
> > implementation.
> 
> Perhaps add a new idle function in common code which can be called
> from various places (including console), and itself calls
> board_poll_devices()? That is cosmetic, but does at least detach the
> code from the console.

No.  This is crap.  If we need a periodic service, we should implement
one, and not add hooks here and there at random.  We already did this
once (for the watchdog triggering), and look what a crap it is. We
should not repeat this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I often quote myself; it adds spice to my conversation.  - G. B. Shaw