linguini1 commented on PR #17221:
URL: https://github.com/apache/nuttx/pull/17221#issuecomment-3434813639

   > Did you even read the summary of PR #14450 ? It doesn't "only say" what 
you claim, but explain the problem that the PR fixes. The ndelay_accurate was 
not very accurate when it quantized the delay to *systick* length. This caused 
e.g. udelay(1) to delay for close to 10000 microseconds instead of busylooping 
for 1 microsecond, on a system with 10ms tick. For any hardware driver 
initialization, where one needed to wait for a few hundred nanoseconds, the 
udelay(1) was commontly used. With the "accurate" ndelay everything just blew 
up.
   
   Sorry @jlaitine , I didn't mean to imply that's all your PR said. I should 
have worded a bit better. What I mean is, your PR points out this flaw with the 
"accurate timer", namely that it's not very accurate for short sleep times 
where the busy wait excels. I agree with your assessment entirely. But, the PR 
doesn't mention any affected drivers or subsystems that broke (to my knowledge, 
writing this on the bus from memory), rather just that the delay time is 
suboptimal. However, in this PR, I do reintroduce a sleep method that is 
suboptimal for short delays like you mentioned, but it's actively fixing the 
SIM architecture which does not respect delays at all, broken.
   
   > So when you revert that, please make sure that it doesn't happen again.
   
   You're right, I want a better solution than just reverting. Right now that 
seems like the lesser evil to me (worse short delay times for respected delays 
on sim). Do you have any ideas for how we can improve the implementation in 
general that would help both scenarios (i.e more accurate than both the old 
implementation and the busy wait)?
   
   > I made a fix for mpfs to use architecture specific delays, which really 
check the time from a timer when busylooping, and that is of course the way to 
go. But *not* using the current time from oneshot_current, which calculated it 
from the tick! For other platforms, such as arm64, the issue will be back.
   
   arm64 should also have a good, accurate timer like mpfs to fix this, right? 
Do you think that @anchao 's recent replacement of up_delay functions with 
nxsched_delay would resolve this problem?
   
   Please let me know what you think, I really value your input and I didn't 
mean to be reductive about your PR.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to