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 likepolling is required to monitor status of variety of devices.For such situations CONFIG_BOARD_POLL shall be enabledand 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.
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.
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.
- 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