2021년 6월 5일 (토) 오후 11:53, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>님이 작성:
> you would need to use:
>
> usleep_range(min_delay_us, max_delay_us);
>
> instead of:
>
> schedule_timeout_interruptible(schedule_delay);
>
> in order to tell the realtime clock about a dead line for
> sleeping.
>
> Thanks,
> Mauro
Okay, I have tried `usleep_range()` instead, and it indeed shows
improvement in the frame rate.
Now it's basically the same as before my patch, except for
`jiffies_to_usecs()` and then `usleep_range()`.
...
int schedule_delay;
+ uint64_t schedule_delay_us;
try_to_freeze();
...
if (time_after(jiffies, start_jiffies + delay))
schedule_delay = delay;
- schedule_timeout_interruptible(schedule_delay);
+ schedule_delay_us = jiffies_to_usecs(schedule_delay);
+ usleep_range(schedule_delay_us * 3/4, schedule_delay_us);
} while (!kthread_should_stop());
return 0;
...
I decided to keep the `if (...) schedule_delay = delay;` part.
The concern was that my RPi Zero was having quite a bit of constant
drift, like showing 3FPS when set to 4FPS, 6FPS when 8FPS, 10FPS when
16FPS, and so on.
Now that I've confirmed the timing's good enough (usually ~0.5 FPS
faster than the frame rate given), there's no need for me to bother
anymore.
I'll send another patchset if it doesn't look too bad.
Thank you very much.
Seongyong Park
