Searched hist:"6 e8c09bb8d60a0b905295e9e2c999b39953c5bf3" (Results 1 – 4 of 4) sorted by relevance
| /openbmc/linux/drivers/media/test-drivers/vivid/ |
| H A D | vivid-kthread-touch.c | diff 6e8c09bb8d60a0b905295e9e2c999b39953c5bf3 Fri Oct 02 09:48:03 CDT 2020 Hans Verkuil <hverkuil-cisco@xs4all.nl> media: vivid: fix (partially) timing issues
The vivid driver is a bit flaky w.r.t. the kthread timing, esp. when
running inside a virtual machine.
This is caused by calling schedule_timeout_uninterruptible(1) which can
actually take more than one jiffie. A while loop with schedule() turns out
to be a lot more precise. Also, if mutex_trylock() fails, then just call
schedule() instead of schedule_timeout_uninterruptible(1). There is no need
to wait until the next jiffer, just schedule(), then try to get the lock
again.
This is still not precise enough, it is still relatively easy to get missed
frames. This really should be converted to use a proper timer, but for now
this solves the worst problems.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
| H A D | vivid-kthread-out.c | diff 6e8c09bb8d60a0b905295e9e2c999b39953c5bf3 Fri Oct 02 09:48:03 CDT 2020 Hans Verkuil <hverkuil-cisco@xs4all.nl> media: vivid: fix (partially) timing issues
The vivid driver is a bit flaky w.r.t. the kthread timing, esp. when
running inside a virtual machine.
This is caused by calling schedule_timeout_uninterruptible(1) which can
actually take more than one jiffie. A while loop with schedule() turns out
to be a lot more precise. Also, if mutex_trylock() fails, then just call
schedule() instead of schedule_timeout_uninterruptible(1). There is no need
to wait until the next jiffer, just schedule(), then try to get the lock
again.
This is still not precise enough, it is still relatively easy to get missed
frames. This really should be converted to use a proper timer, but for now
this solves the worst problems.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
| H A D | vivid-sdr-cap.c | diff 6e8c09bb8d60a0b905295e9e2c999b39953c5bf3 Fri Oct 02 09:48:03 CDT 2020 Hans Verkuil <hverkuil-cisco@xs4all.nl> media: vivid: fix (partially) timing issues
The vivid driver is a bit flaky w.r.t. the kthread timing, esp. when
running inside a virtual machine.
This is caused by calling schedule_timeout_uninterruptible(1) which can
actually take more than one jiffie. A while loop with schedule() turns out
to be a lot more precise. Also, if mutex_trylock() fails, then just call
schedule() instead of schedule_timeout_uninterruptible(1). There is no need
to wait until the next jiffer, just schedule(), then try to get the lock
again.
This is still not precise enough, it is still relatively easy to get missed
frames. This really should be converted to use a proper timer, but for now
this solves the worst problems.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|
| H A D | vivid-kthread-cap.c | diff 6e8c09bb8d60a0b905295e9e2c999b39953c5bf3 Fri Oct 02 09:48:03 CDT 2020 Hans Verkuil <hverkuil-cisco@xs4all.nl> media: vivid: fix (partially) timing issues
The vivid driver is a bit flaky w.r.t. the kthread timing, esp. when
running inside a virtual machine.
This is caused by calling schedule_timeout_uninterruptible(1) which can
actually take more than one jiffie. A while loop with schedule() turns out
to be a lot more precise. Also, if mutex_trylock() fails, then just call
schedule() instead of schedule_timeout_uninterruptible(1). There is no need
to wait until the next jiffer, just schedule(), then try to get the lock
again.
This is still not precise enough, it is still relatively easy to get missed
frames. This really should be converted to use a proper timer, but for now
this solves the worst problems.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
|