<div dir="ltr"><div dir="ltr">Hi Laurent,<div><br></div><div>Thank you for your review feedback. Sending again, as I forgot to reply-all.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 27 Jan 2021 at 00:30, Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com">laurent.pinchart@ideasonboard.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Naush,<br>
<br>
Thank you for the patch.<br>
<br>
On Sun, Jan 24, 2021 at 02:05:06PM +0000, Naushir Patuck wrote:<br>
> If an exposure time change adjusts the vblanking limits, and we write<br>
> both VBLANK and EXPOSURE controls as a set, the latter may fail if the<br>
> value is outside of the limits calculated by the old VBLANK value. This<br>
> is a limitation in V4L2 and cannot be fixed by writing VBLANK before<br>
> EXPOSURE.<br>
> <br>
> The workaround here is to have the StaggeredCtrl mark the<br>
> VBLANK control as "immediate write", which then write VBLANK separately<br>
> from (and ahead of) any other controls. This way, the sensor driver will<br>
> update the EXPOSURE control with new limits before the new values is<br>
> presented, and will thus be seen as valid.<br>
> <br>
> StaggeredCtrl is due to be deprecated and replaced by DelayedCtrl, so<br>
> this change serves more a working proof-of-concept on the workaround,<br>
> and not much care has been taken to provide a nice new API for applying<br>
> this immediate write flag to the control. A similar workaround must be<br>
> available to DelayedCtrl eventually.<br>
> <br>
> Signed-off-by: Naushir Patuck <<a href="mailto:naush@raspberrypi.com" target="_blank">naush@raspberrypi.com</a>><br>
> ---<br>
> src/ipa/raspberrypi/raspberrypi.cpp | 5 ++-<br>
> .../pipeline/raspberrypi/raspberrypi.cpp | 11 ++++--<br>
> .../pipeline/raspberrypi/staggered_ctrl.cpp | 39 ++++++++++++++-----<br>
> .../pipeline/raspberrypi/staggered_ctrl.h | 3 +-<br>
> 4 files changed, 43 insertions(+), 15 deletions(-)<br>
> <br>
> diff --git a/src/ipa/raspberrypi/raspberrypi.cpp b/src/ipa/raspberrypi/raspberrypi.cpp<br>
> index 75c9e404dcc1..fefca32ce187 100644<br>
> --- a/src/ipa/raspberrypi/raspberrypi.cpp<br>
> +++ b/src/ipa/raspberrypi/raspberrypi.cpp<br>
> @@ -1040,8 +1040,9 @@ void IPARPi::applyAGC(const struct AgcStatus *agcStatus, ControlList &ctrls)<br>
> <br>
> /*<br>
> * Due to the behavior of V4L2, the current value of VBLANK could clip the<br>
> - * exposure time without us knowing. The next time though this function should<br>
> - * clip exposure correctly.<br>
> + * exposure time without us knowing. We get around this by ensuring the<br>
> + * staggered write component submits VBLANK separately from, and before the<br>
> + * EXPOSURE control.<br>
> */<br>
> ctrls.set(V4L2_CID_VBLANK, vblanking);<br>
> ctrls.set(V4L2_CID_EXPOSURE, exposureLines);<br>
> diff --git a/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp b/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp<br>
> index 524cc960dd37..1485999ad2a0 100644<br>
> --- a/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp<br>
> +++ b/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp<br>
> @@ -1229,12 +1229,17 @@ int RPiCameraData::configureIPA(const CameraConfiguration *config)<br>
> /*<br>
> * Setup our staggered control writer with the sensor default<br>
> * gain and exposure delays.<br>
> + *<br>
> + * VBLANK must be flagged as "immediate write" to allow it to<br>
> + * be set immediately instead of being batched with all other<br>
> + * controls. This is needed so that any update to the EXPOSURE<br>
> + * control will be validated based on the new VBLANK control value.<br>
> */<br>
> if (!staggeredCtrl_) {<br>
> staggeredCtrl_.init(unicam_[Unicam::Image].dev(),<br>
> - { { V4L2_CID_ANALOGUE_GAIN, result.data[resultIdx++] },<br>
> - { V4L2_CID_EXPOSURE, result.data[resultIdx++] },<br>
> - { V4L2_CID_VBLANK, result.data[resultIdx++] } });<br>
> + { { V4L2_CID_ANALOGUE_GAIN, result.data[resultIdx++], false },<br>
> + { V4L2_CID_EXPOSURE, result.data[resultIdx++], false },<br>
> + { V4L2_CID_VBLANK, result.data[resultIdx++], true } });<br>
> sensorMetadata_ = result.data[resultIdx++];<br>
> }<br>
> }<br>
> diff --git a/src/libcamera/pipeline/raspberrypi/staggered_ctrl.cpp b/src/libcamera/pipeline/raspberrypi/staggered_ctrl.cpp<br>
> index 62605c0fceee..07f8c95d4f2c 100644<br>
> --- a/src/libcamera/pipeline/raspberrypi/staggered_ctrl.cpp<br>
> +++ b/src/libcamera/pipeline/raspberrypi/staggered_ctrl.cpp<br>
> @@ -22,21 +22,29 @@ LOG_DEFINE_CATEGORY(RPI_S_W)<br>
> namespace RPi {<br>
> <br>
> void StaggeredCtrl::init(V4L2VideoDevice *dev,<br>
> - std::initializer_list<std::pair<const uint32_t, uint8_t>> delayList)<br>
> + std::initializer_list<std::tuple<uint32_t, uint8_t, bool>> delayList)<br>
<br>
It could make sense to define a struct type to group the three<br>
parameters.<br></blockquote><br class="gmail-Apple-interchange-newline"><div><span style="font-family:Arial,Helvetica,sans-serif">Agree, I will fix this. I was going for the easiest/quickest possible thing here, as this will all be deprecated shortly. </span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> {<br>
> std::lock_guard<std::mutex> lock(lock_);<br>
> <br>
> dev_ = dev;<br>
> - delay_ = delayList;<br>
> + delay_.clear();<br>
> ctrl_.clear();<br>
> <br>
> - /* Find the largest delay across all controls. */<br>
> maxDelay_ = 0;<br>
> - for (auto const &p : delay_) {<br>
> + for (auto const &c : delayList) {<br>
> + uint32_t id = std::get<0>(c);<br>
> + uint8_t delay = std::get<1>(c);<br>
> + bool immediateWrite = std::get<2>(c);<br>
> +<br>
> + delay_[id] = delay;<br>
> + immediateWrite_[id] = immediateWrite;<br>
<br>
"immediate write" isn't a great name, as the control isn't written<br>
immediately, it's still delayed.<br></blockquote><div><br></div><div>How about "priority controls" to signify they must be written ahead of the batch?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> +<br>
> LOG(RPI_S_W, Info) << "Init ctrl "<br>
> - << utils::hex(p.first) << " with delay "<br>
> - << static_cast<int>(p.second);<br>
> - maxDelay_ = std::max(maxDelay_, p.second);<br>
> + << utils::hex(id) << " with delay "<br>
> + << static_cast<int>(delay);<br>
> +<br>
> + /* Find the largest delay across all controls. */<br>
> + maxDelay_ = std::max(maxDelay_, delay);<br>
> }<br>
> <br>
> init_ = true;<br>
> @@ -121,8 +129,21 @@ int StaggeredCtrl::write()<br>
> int index = std::max<int>(0, setCount_ - delayDiff);<br>
> <br>
> if (p.second[index].updated) {<br>
> - /* We need to write this value out. */<br>
> - controls.set(p.first, p.second[index].value);<br>
> + if (immediateWrite_[p.first]) {<br>
> + /*<br>
> + * This control must be written now, it could<br>
> + * affect validity of the other controls.<br>
> + */<br>
> + ControlList immediate(dev_->controls());<br>
> + immediate.set(p.first, p.second[index].value);<br>
> + dev_->setControls(&immediate);<br>
> + } else {<br>
> + /*<br>
> + * Batch up the list of controls and write them<br>
> + * at the end of the function.<br>
> + */<br>
> + controls.set(p.first, p.second[index].value);<br>
> + }<br>
> p.second[index].updated = false;<br>
> LOG(RPI_S_W, Debug) << "Writing ctrl "<br>
> << utils::hex(p.first) << " to "<br>
> diff --git a/src/libcamera/pipeline/raspberrypi/staggered_ctrl.h b/src/libcamera/pipeline/raspberrypi/staggered_ctrl.h<br>
> index 382fa31a6853..7c920c3a13c7 100644<br>
> --- a/src/libcamera/pipeline/raspberrypi/staggered_ctrl.h<br>
> +++ b/src/libcamera/pipeline/raspberrypi/staggered_ctrl.h<br>
> @@ -34,7 +34,7 @@ public:<br>
> }<br>
> <br>
> void init(V4L2VideoDevice *dev,<br>
> - std::initializer_list<std::pair<const uint32_t, uint8_t>> delayList);<br>
> + std::initializer_list<std::tuple<uint32_t, uint8_t, bool>> delayList);<br>
> void reset();<br>
> <br>
> void get(std::unordered_map<uint32_t, int32_t> &ctrl, uint8_t offset = 0);<br>
> @@ -85,6 +85,7 @@ private:<br>
> uint8_t maxDelay_;<br>
> V4L2VideoDevice *dev_;<br>
> std::unordered_map<uint32_t, uint8_t> delay_;<br>
> + std::unordered_map<uint32_t, bool> immediateWrite_;<br>
<br>
Should we store both the delay and the immediate write flag in a single<br>
map ?<br></blockquote><div><br></div><div><span style="font-family:Arial,Helvetica,sans-serif">If we use a structure to group things in the constructor, this can change to a structure as well. We can then store both in a single map. </span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Otherwise this looks fine. We could possibly solve these issues as part<br>
of the DelayedControls work. I'll let Niklas discuss his preference.<br></blockquote><div><br></div><div>Yes, as I mentioned in the cover letter, DelayedControls does not necessarily need this functionality on day 1. This change is more of an outline as to how we can get around the problem.</div><div><br></div><div>Regards,</div><div><span style="font-family:Arial,Helvetica,sans-serif">Naush</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> std::unordered_map<uint32_t, CircularArray> ctrl_;<br>
> std::mutex lock_;<br>
> };<br>
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br>
</blockquote></div></div>