Message ID | 1355223289-15685-5-git-send-email-hatim.rv@samsung.com |
---|---|
State | Changes Requested |
Delegated to: | Minkyu Kang |
Headers | show |
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
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. + - CONFIG_SYS_BAUDRATE_TABLE: List of legal baudrate settings for this board. diff --git a/common/console.c b/common/console.c index 1177f7d..d320b9b 100644 --- a/common/console.c +++ b/common/console.c @@ -117,6 +117,11 @@ static int console_tstc(int file) int i, ret; struct stdio_dev *dev; +#if defined CONFIG_BOARD_POLL + /* Generic polling function */ + board_poll_devices(); +#endif + disable_ctrlc(1); for (i = 0; i < cd_count[file]; i++) { dev = console_devices[file][i]; diff --git a/include/common.h b/include/common.h index 5e3c5ee..b6f563b 100644 --- a/include/common.h +++ b/include/common.h @@ -778,6 +778,12 @@ void clear_ctrlc (void); /* clear the Control-C condition */ int disable_ctrlc (int); /* 1 to disable, 0 to enable Control-C detect */ /* + * A generic polling function. + * This will be called form console_tstc() to poll for various events. + */ +void board_poll_devices(void); + +/* * STDIO based functions (can always be used) */ /* serial stuff */