Conversation
efa0310 to
6f7107b
Compare
6f7107b to
48ba020
Compare
48ba020 to
1815833
Compare
1815833 to
5a4c9b3
Compare
Every channel start busy-waits for one second after the firmware starts capture. This occupies a CPU while waiting for automatic exposure even though this path can sleep. Replace mdelay() with msleep(), keeping the one-second settling delay. The wait no longer keeps a CPU busy; its duration is unchanged apart from scheduler timing. Adjusting the settling time is a separate change. Based-on: patjak#334
The fixed settling delay is paid on every STREAMON, including restarts during format negotiation. A one-second wait therefore adds substantial latency to opening or reconfiguring the camera. Reduce the sleep to 200 ms. This removes 800 ms from the requested wait; complete stream startup also includes firmware commands and scheduling. The corrected series starts capture in about 290 ms on the tested MacBookPro14,1. The delay remains a fixed allowance rather than a firmware readiness check. Settling on other sensors and white-balance convergence still need validation; a successful stream start does not establish either. Based-on: patjak#334
5a4c9b3 to
041d624
Compare
|
Updated the branch onto master The two logical changes remain separate: first replace The revised individual branch builds against Linux 7.1.13+deb14-amd64 with Revision: |
2 participants
The auto-exposure wait in
fthd_start_channel()goes frommdelay(1000)tomsleep(200). It is paid on everyVIDIOC_STREAMON, not once per open.Two commits, because they do different things. Measured on a MacBookPro14,1, mean of five repetitions each against a module built from clean master, min and max in brackets:
The
msleepshortens nothing — it stops burning a CPU for the second. The 200 ms is what shortens the wait. Taking the value change without themsleepwould mean 200 ms of a busy-held CPU instead of 1000, which is an improvement of the wrong kind, so both are here.Why 200. The value has been 1000 ms since 2015 and there is nothing in the history behind it. Sweeping it as a module parameter, four interleaved repetitions per value with the light held constant, each run compared against its own final brightness: from 100 ms up the first frame already has the brightness the stream settles on; at 50 ms and below it comes out black. Repeated with 60 s of idle before each run so the exposure could not start from the previous state — 100 ms still good, three times out of three. 200 ms is twice the smallest value that worked.
Worth pointing at: a full second is not even the better choice. It delivers a first frame 10% brighter than where the stream settles, where 100 ms lands on it.
What this does not cover. One camera, and the measurement is of luma only — if the wait was also protecting the white balance, this would not have seen it. The driver also still waits blind rather than polling the firmware's
CISP_CMD_CH_AE_*state; if someone who knows the ISP wants to replace the wait with a poll, this patch should be thrown away in favour of that.The series
One of nine open PRs on this driver; the others are #331, #338, #340, #342, #343, #344, #345 and #347. They apply independently, with two exceptions: #344 contains the first commit of #343, and #331 should go in together with #347.