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

From: Akshay Saraswat <akshay.s@samsung.com>

Adding a generic polling function to continuously monitor events and
trigger actions corresponding to them.

Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
Acked-by: Simon Glass <sjg@chromium.org>

Dear Hatim Ali,

In message <1355223289-15685-5-git-send-email-hatim.rv@samsung.com> you wrote:
> From: Akshay Saraswat <akshay.s@samsung.com>
> 
> Adding a generic polling function to continuously monitor events and
> trigger actions corresponding to them.
> 
> Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
> Acked-by: Simon Glass <sjg@chromium.org>
> 
> diff --git a/README b/README
> index 037513a..0e4083c 100644
> --- a/README
> +++ b/README
> @@ -2841,6 +2841,13 @@ Configuration Settings:
>  		the application (usually a Linux kernel) when it is
>  		booted
>  
> +- CONFIG_BOARD_POLL
> +	There are various scenarios in which parallel-thread like
> +	polling is required to monitor status of variety of devices.
> +	For such situations CONFIG_BOARD_POLL shall be enabled
> +	and funtion call board_poll_devices() from console_tstc()
> +	will then poll for the device status as defined inside function.


Sorry, but I dislike this, for a number of reasons.

1) There is, and has always been, a very basic design decision, that
   U-Boot is strictly single-tasking, i. e. we don't have any kind of
   "background activities" goind on.  Your introduction of a device
   polling mechanism violates this principle.

   I don't say that this is unacceptable, but we have to be aware that
   this is a far-reaching decision, so we should consider it very
   carefully.

   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.

2) U-Boot is a boot loader, not an OS.  Do we really need continuous
   temperature management in U-Boot?  I think not.  After all, our
   main purpose is to boot an OS, and do that as fast as possible.
   The majority of users will see U-Boot running only for a few
   milliseconds, and only when they boot the device - which may be
   very seldom.

   So what exactly do we need this for?

3) Your hooking of a device polling into console_tstc() is broken by
   design.   It may be sufficient for the specific use case you have
   in mind here, but it is totally useless for any other purpose.

This needs a lot of additional thought, and major changes to the
implementation.

Best regards,

Wolfgang Denk

Hi Wolfgang,

On Tue, Dec 11, 2012 at 4:39 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Hatim Ali,
>
> In message <1355223289-15685-5-git-send-email-hatim.rv@samsung.com> you wrote:
>> From: Akshay Saraswat <akshay.s@samsung.com>
>>
>> Adding a generic polling function to continuously monitor events and
>> trigger actions corresponding to them.
>>
>> Signed-off-by: Akshay Saraswat <akshay.s@samsung.com>
>> Acked-by: Simon Glass <sjg@chromium.org>
>>
>> diff --git a/README b/README
>> index 037513a..0e4083c 100644
>> --- a/README
>> +++ b/README
>> @@ -2841,6 +2841,13 @@ Configuration Settings:
>>               the application (usually a Linux kernel) when it is
>>               booted
>>
>> +- CONFIG_BOARD_POLL
>> +     There are various scenarios in which parallel-thread like
>> +     polling is required to monitor status of variety of devices.
>> +     For such situations CONFIG_BOARD_POLL shall be enabled
>> +     and funtion call board_poll_devices() from console_tstc()
>> +     will then poll for the device status as defined inside function.
>
>
> Sorry, but I dislike this, for a number of reasons.
>
> 1) There is, and has always been, a very basic design decision, that
>    U-Boot is strictly single-tasking, i. e. we don't have any kind of
>    "background activities" goind on.  Your introduction of a device
>    polling mechanism violates this principle.
>
>    I don't say that this is unacceptable, but we have to be aware that
>    this is a far-reaching decision, so we should consider it very
>    carefully.
>
>    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.

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.

>
> 2) U-Boot is a boot loader, not an OS.  Do we really need continuous
>    temperature management in U-Boot?  I think not.  After all, our
>    main purpose is to boot an OS, and do that as fast as possible.
>    The majority of users will see U-Boot running only for a few
>    milliseconds, and only when they boot the device - which may be
>    very seldom.
>
>    So what exactly do we need this for?

It is possible that the OS cannot be found or is corrupted due to some
sort of failure or error. In that case we may need to prompt the user
to insert media that can be used to recover the device. If the secure
boot is turned off, we may want to print a warning and require that
the user confirm. In both cases, we can be in U-Boot for a while.

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.

>
> 3) Your hooking of a device polling into console_tstc() is broken by
>    design.   It may be sufficient for the specific use case you have
>    in mind here, but it is totally useless for any other purpose.
>
> 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.

Regards,
Simon

>
> 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@denx.de
> Without facts, the decision cannot be made logically. You  must  rely
> on your human intuition.
>         -- Spock, "Assignment: Earth", stardate unknown
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Dear Simon Glass,

In message <CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6WQ4CDOb0zQMgi7XwGwWBQ@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

Hi Wolfgang,

On Wed, Dec 12, 2012 at 12:44 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ3VedAoM9tkzHoHWPi9cAJ=6WQ4CDOb0zQMgi7XwGwWBQ@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.

Well that means interrupts. Are you suggesting that we implement
generic timers and allow drivers to register a timer callback function
to be called periodically? That seems like a bold move, but we could
do it.

>
>> 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?

Firstly we can detect that the system is idle (by noticing that it has
been long time since a keypress, for example), and reduce the CPU
clock speed until we next see a key. This might be enough to remove
the problem. Perhaps we should add some sort of feature to console to
record the time of last key input to facilitate that. There are lots
of ways to do it.

Secondly, when the system warms up we can display a warning on the
console, and perhaps reduce CPU speed further.

Thirdly, when the system starts to melt, we can power it off.

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

Yes, but perhaps only by running very slowly. In the normal case we
are only in U-Boot for a short period so want to run at full speed.

>
>> > 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.

Yes I'm not a big fan of putting calls everywhere, but in a sense this
is pointing us towards an idle loop, something that we declare must be
called periodically for U-Boot to function. A timer doesn't
necessarily suit the watchdog, since we may have locked up in an
infinite loop somewhere due to a s/w or h/w problem - in that case we
don't want to kick the watchdog on an interval, only when we know that
the system is happy.

So it seems that some sort of timer hook might be good for the patch
under discussion, but for the watchdog we need an idle loop or
similar. The timer hook does open a bit of a can of worms for other
reasons - e.g. you are in the middle of an i2c transaction, the timer
fires, you jump to the temperature monitor which wants to use i2c to
find out the temperature. I thought we wanted to avoid this sort of
thing in U-Boot so long as possible.

We could perhaps add an 'idle hook' so that callers can register themselves:

int idle_register_handler(int (*callback_fn)(void), void *priv);
int idle_free_handler(int (*callback_fn)(void), void *priv);

define an idle handler:

void idle_poll(void)
{
         WATCHDOG_RESET();
         (loop through registered handlers and call them)
}

and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.

We could perhaps have a flags parameter to permit selection of what
sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog
reset, IDLE_POLL_ALL to call all the registered handlers).

The hooks could then be generalised to support timers, with the
proviso that timers are only ever invoked from the idle loop so that
there is little possibility of strange things happening. That might
get around the timer interrupt problem I mentioned above.

Any of the above is much more radical than this patch.

Regards,
Simon

>
> 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@denx.de
> I often quote myself; it adds spice to my conversation.  - G. B. Shaw

Dear Simon Glass,

In message <CAPnjgZ0bmsJAx4MAk-+GLo+QLC-6zbgp24N=BNqO=2fsUikjDw@mail.gmail.com> you wrote:
> 
> > 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.
> 
> Well that means interrupts. Are you suggesting that we implement
> generic timers and allow drivers to register a timer callback function
> to be called periodically? That seems like a bold move, but we could
> do it.

Which architectures do not use interrupts for the timer services?

> > How would one recover from that?
> 
> Firstly we can detect that the system is idle (by noticing that it has
> been long time since a keypress, for example), and reduce the CPU
> clock speed until we next see a key. This might be enough to remove
> the problem. Perhaps we should add some sort of feature to console to

No, this is just a crappy design.

Assume you load some big image and write it to NAND (or you do other
operations that take some time; eventually in a loop).  Your keyboard
dependet code would not trigger here, and you would just overheat the
system.

I mean, what good is such protection when a simple "while : ; do : ;
done" will just toast your box?

> record the time of last key input to facilitate that. There are lots
> of ways to do it.

Sorry, but keyboard activity has _nothing_ to do ith it and is the
totally wrong place to attach such functionality to.

> Secondly, when the system warms up we can display a warning on the
> console, and perhaps reduce CPU speed further.
> 
> Thirdly, when the system starts to melt, we can power it off.

Would you ever buy such a design?  I wouldn't.  And any competing
company would probably have excellent arguments for their own
marketing material.

> So it seems that some sort of timer hook might be good for the patch
> under discussion, but for the watchdog we need an idle loop or

I don;t understand your arguments here.  You are aware that we don;t
really have watchdog support in U-Boot (not in the sense that we
monitor U-Boot's operation) - we only make sure to trigger it
periodically.

> similar. The timer hook does open a bit of a can of worms for other
> reasons - e.g. you are in the middle of an i2c transaction, the timer
> fires, you jump to the temperature monitor which wants to use i2c to
> find out the temperature. I thought we wanted to avoid this sort of
> thing in U-Boot so long as possible.

Yes, we definitely do want to avoid this, which is the reson why I
insist on asking of we actually need such a feature in U-Boot.  If the
hardware cannot protect itself sufficiently and relies on software
support, you are doomed anyway, because somebody will always just do
some stupid things and find out that he detected a HCF macro...

> We could perhaps add an 'idle hook' so that callers can register themselves:

Where exactly would you hook that to, if not to some timer interrupt?

ANd please tink about this again - if you talk about an 'idle hook',
you actually are talking about an "idle task", i. e. about introducing
a multi-task concept (even if it's just a simple one).

This is not exactly a small can of worms, and I guess these worms have
a smell ...

> and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.

Oh.  Cooperative multitasking...

Are you really, really sure we want to do that?

> We could perhaps have a flags parameter to permit selection of what
> sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog
> reset, IDLE_POLL_ALL to call all the registered handlers).
> 
> The hooks could then be generalised to support timers, with the
> proviso that timers are only ever invoked from the idle loop so that

Yes, we can do all that.  We can actually implement a full-blown OS.

Are you really, really sure we want to do that?

> Any of the above is much more radical than this patch.

But the patch as submitted here is not even functional...

Best regards,

Wolfgang Denk

Hi Wolfgang,

On Wed, Dec 12, 2012 at 2:11 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Simon Glass,
>
> In message <CAPnjgZ0bmsJAx4MAk-+GLo+QLC-6zbgp24N=BNqO=2fsUikjDw@mail.gmail.com> you wrote:
>>
>> > 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.
>>
>> Well that means interrupts. Are you suggesting that we implement
>> generic timers and allow drivers to register a timer callback function
>> to be called periodically? That seems like a bold move, but we could
>> do it.
>
> Which architectures do not use interrupts for the timer services?

For example some ARM implementations just have a hardware counter that
we can read. It doesn't roll over so no need for interrupts.

>
>> > How would one recover from that?
>>
>> Firstly we can detect that the system is idle (by noticing that it has
>> been long time since a keypress, for example), and reduce the CPU
>> clock speed until we next see a key. This might be enough to remove
>> the problem. Perhaps we should add some sort of feature to console to
>
> No, this is just a crappy design.
>
> Assume you load some big image and write it to NAND (or you do other
> operations that take some time; eventually in a loop).  Your keyboard
> dependet code would not trigger here, and you would just overheat the
> system.
>
> I mean, what good is such protection when a simple "while : ; do : ;
> done" will just toast your box?

Well it will force a hard power off - the hardware has a hard limit at
which it will power off. Don't do that! The more common case is the
user sitting at a prompt doing nothing, and that's the case which
prompted this patch I think.

>
>> record the time of last key input to facilitate that. There are lots
>> of ways to do it.
>
> Sorry, but keyboard activity has _nothing_ to do ith it and is the
> totally wrong place to attach such functionality to.

Can you suggest an alternative place which gives us an indicator of
user activity?

>
>> Secondly, when the system warms up we can display a warning on the
>> console, and perhaps reduce CPU speed further.
>>
>> Thirdly, when the system starts to melt, we can power it off.
>
> Would you ever buy such a design?  I wouldn't.  And any competing
> company would probably have excellent arguments for their own
> marketing material.

So long as it had some fail safe power off when things get hot it is
ok. But we need to try to avoid getting into that condition. Running
flat out at 1.7GHz waiting for keyboard input that may never come is
not good design.

>
>> So it seems that some sort of timer hook might be good for the patch
>> under discussion, but for the watchdog we need an idle loop or
>
> I don;t understand your arguments here.  You are aware that we don;t
> really have watchdog support in U-Boot (not in the sense that we
> monitor U-Boot's operation) - we only make sure to trigger it
> periodically.

Yes I was responding to your complaint about how watchdogs currently
work. It is ugly that things like hashing functions need a parameter
telling them when to reset, and have watchdog calls in the algorithm.

>
>> similar. The timer hook does open a bit of a can of worms for other
>> reasons - e.g. you are in the middle of an i2c transaction, the timer
>> fires, you jump to the temperature monitor which wants to use i2c to
>> find out the temperature. I thought we wanted to avoid this sort of
>> thing in U-Boot so long as possible.
>
> Yes, we definitely do want to avoid this, which is the reson why I
> insist on asking of we actually need such a feature in U-Boot.  If the
> hardware cannot protect itself sufficiently and relies on software
> support, you are doomed anyway, because somebody will always just do
> some stupid things and find out that he detected a HCF macro...

Hopefully we have covered this now. HCF will cause a hard power off
eventually, but we don't want sitting idle at the prompt to be
equivalent to HCF.

>
>> We could perhaps add an 'idle hook' so that callers can register themselves:
>
> Where exactly would you hook that to, if not to some timer interrupt?

Console input, places where the watchdog is currently reset, for example.

>
> ANd please tink about this again - if you talk about an 'idle hook',
> you actually are talking about an "idle task", i. e. about introducing
> a multi-task concept (even if it's just a simple one).
>
> This is not exactly a small can of worms, and I guess these worms have
> a smell ...
>
>> and then change all the WATCHDOG_RESET() calls to call idle_poll() instead.
>
> Oh.  Cooperative multitasking...
>
> Are you really, really sure we want to do that?

Actually I was happy enough with a simple patch to indicate idle in
the console code :-)

>
>> We could perhaps have a flags parameter to permit selection of what
>> sort of things to poll - e.g. IDLE_POLL_WATCHDOG for a quick watchdog
>> reset, IDLE_POLL_ALL to call all the registered handlers).
>>
>> The hooks could then be generalised to support timers, with the
>> proviso that timers are only ever invoked from the idle loop so that
>
> Yes, we can do all that.  We can actually implement a full-blown OS.
>
> Are you really, really sure we want to do that?

  <1>                <2>                  <3>                    <4>
this patch       idle support      co-op multitasking         full-blown OS


Please choose :/) I think you are saying that <1> is too much of a
hack. Clearly <4> is not why we are here. I suggest <1>, or failing
that, <2>. I think <3> is scary and I think there is clear daylight
between <2> and <3>.

But if you can accept that this feature is useful, how would you implement it?

>
>> Any of the above is much more radical than this patch.
>
> But the patch as submitted here is not even functional...

It seems to work as intended, albeit I'm sure there are flaws.

>
> Best regards,
>
> Wolfgang Denk
>
> --

Regards,
Simon


> 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@denx.de
> Weekends were made for programming.                 - Karl Lehenbauer

Dear Simon Glass,

In message <CAPnjgZ05L+CpbQphaD6Of3zR1hst2YL3pK86=yMC79UtRxvjXQ@mail.gmail.com> you wrote:
> 
> > I mean, what good is such protection when a simple "while : ; do : ;
> > done" will just toast your box?
> 
> Well it will force a hard power off - the hardware has a hard limit at
> which it will power off. Don't do that! The more common case is the
> user sitting at a prompt doing nothing, and that's the case which
> prompted this patch I think.

Let me summarize the facts and arguments as far as I understand these
so far:

- There is built-in hardware protection; if we don't apply this patch,
  nothing gets broken, but the system will power off when overheating.

- The normal mode of operation s to boot an OS as quickly as possible,
  without any user interaction, so this patch is not needed, nor would
  the code be used at all.

- In the few cases where we don't boot an OS quickly, we assume that
  the only long-running activity that needs protection is waiting for
  user input.

- If we spend too much time in U-Boot and te system overheats, then we
  power it down.


I have these comments:

* The assumption, that only waiting for keyboard input is a critical
  operation, is obviously broken.

* If we just power down, we can as well use the hardware-triggered
  power down; the effect would be the same?

I can only repeat myself:
- what would be needed here is an asynchronous (periodic) service
- hooking this onto keyboard activity is broken by design
- we don't have any other generic mechanism to implement such a
  feature yet.

> > Sorry, but keyboard activity has _nothing_ to do ith it and is the
> > totally wrong place to attach such functionality to.
> 
> Can you suggest an alternative place which gives us an indicator of
> user activity?

Please stop thinking about user activity.  It has _nothing_ to do with
it.  What you are looking for is a time triggered service - you want
to make sure to run your temperature control code at least every N
milliseconds.

> So long as it had some fail safe power off when things get hot it is
> ok. But we need to try to avoid getting into that condition. Running
> flat out at 1.7GHz waiting for keyboard input that may never come is
> not good design.

Why are we running at such a high clock anyway in U-Boot?  Most
activities in U-Boot are limited by I/O troughput and/or memory
bandwidth.  There are very few exceptions: uncompressing and
checksumming an OS image when boting it are such; at the moment I
cannot think of any other that might be significant in the sense that
they would play any role for boot times in the majority of use cases
(just booting an OS).

So why not simply run U-Boot at a much lower clock?  Has anybody
measured how many milliseconds of boot time that would cost?

And, if needed, you could still rev up the clock rate when actually
running the bootm code where speed actually plays a role...


> Actually I was happy enough with a simple patch to indicate idle in
> the console code :-)

I fail to understand why you don't accept the fact that this does not
even work?

>   <1>                <2>                  <3>                    <4>
> this patch       idle support      co-op multitasking         full-blown OS
> 
> 
> Please choose :/) I think you are saying that <1> is too much of a
> hack. Clearly <4> is not why we are here. I suggest <1>, or failing
> that, <2>. I think <3> is scary and I think there is clear daylight
> between <2> and <3>.

My vote is to none of this.

> But if you can accept that this feature is useful, how would you implement it?

I am pretty much convinced that the chosen approach is wrong, and that
we do no actually need any such feature here.

I am very sure that hooking this into console code is totally wrong,
as the heating up takes place independent of any user interaction.

I also challenge the assumption that periodic polling is needed.
I don't know the hardware inplace, but most likely it is capable of
actively signalling that overheating takes place - I guess you can
program a maximum temperatrue and it will raise an interrupt if this
is reached?  If so, temperature control should be implemented in an
event-driven way, and not using polling.

If in the end we still should find we need to implement an
asynchronous, time-triggered service, then this should be implemented
based on a periodic timer interrupt.

> > But the patch as submitted here is not even functional...
> 
> It seems to work as intended, albeit I'm sure there are flaws.

It works only as long as you do not anything which cases  U-Boot to
run for too long before returning to the console - and run time is
totally out of your control.  In other words: it is just good for a
demo and to collect brownie points from some bosses.  Would you drive
a car where the operation of the safety belt was similarly reliable?

Best regards,

Wolfgang Denk