Am 25.04.2016 um 07:46 schrieb Heiko Schocher: > Hello Boris, > > Am 22.04.2016 um 14:21 schrieb Boris Brezillon: >> On Fri, 22 Apr 2016 13:53:00 +0200 >> Heiko Schocher <[email protected]> wrote: >> >>> >>>> An alternative approach would be not executing work >>>> directly while scheduling it but in produce_free_peb(). >>>> UBI is designed to work with the worker being disabled. >>>> All UBI work will then happen synchronous and should also work >>>> in u-boot. >>> >>> Sounds good! >> >> Not so good actually. I tried that, and ended up with tasks stalled in >> the work queue because the implementation was never "scheduling" the >> do_work() loop. >> >> Let's keep it simple, in uboot everything is synchronous, and you can't >> be preempted by another task, so it's safe to assume that "scheduling a >> work" == "executing it right away". IMHO, the kernel should also assume >> that "scheduling a work" might involve "the work may have been done >> before the ubi_schedule_work() function returns": when you schedule a >> work to be done and wake up the thread responsible for dequeuing UBI >> works, the scheduler can decide to schedule this thread right away, >> which means this work can be done before the caller gets back to the >> instruction just after ubi_schedule_work(). >> >> Of course, this has to be nuanced for the "attach procedure", because at >> this time the UBI thread is not launched yet. But even in this >> specific case, I think it's safer to assume that, maybe one day, the UBI >> thread might be running when ubi_wl_init() is called, which is why I >> suggested to also apply this patch to Linux. > > Ok, thanks for this explanation! I posted this patch also on linux-mtd, see: > > https://patchwork.ozlabs.org/patch/613492/
Let's hope that attaching is the only place. :-) Heiko, it would be cool if you could double check. Thanks, //richard _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
