On Mon, Feb 13, 2017 at 8:43 PM, Andrey Petrov andrey.petrov@intel.com wrote:
Hi,
On 02/13/2017 12:31 PM, ron minnich wrote:
Another idea just popped up: Performing "background" tasks in udelay() / mdelay() implementations ;)that is adurbin's threading model. I really like it.
A lot of times, concurrency will get you just as far as ||ism without the nastiness.
But how do you guarantee code will get a slice of execution time when it needs it? For example for eMMC link training you need to issue certain commands with certain time interval. Lets say every 10ms. How do you make sure that happens? You can keep track of time and see when next piece of work needs to be scheduled, but how do you guarantee you enter this udelay code often enough?
You can't guarantee anything like that. You'd need compiler help for yielding at loop and function boundaries. Or you go the interrupt route and reschedule. Or you use the other CPUs like you already mentioned.
coreboot code base is not currently sympathetic to multiple threads with full pre-emption. The threads currently provided in coreboot do yielding in udelay calls as a safe place to reschedule. That by no means provides any latency guarantees and since we have no concept of work we can't ensure there's a guaranteed latency between each chunk of work.
Andrey
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot