Hi Ricardo,
On 02/17/15 12:02, Ricardo Ribalda Delgado wrote:
> Volatile controls can change their value outside the v4l-ctrl framework.
>
> We should ignore the cached written value of the ctrl when evaluating if
> we should run s_ctrl.
>
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@xxxxxxxxx>
> ---
>
> I have a control that tells the user when there has been a external trigger
> overrun. (Trigger while processing old image). This is a volatile control.
Does the application just read the control to check whether the trigger happened?
Or is the control perhaps changed by an interrupt handler?
> The user writes 0 to the control, to ack the error condition, and clear the
> hardware flag.
Would it be an idea to automatically ack the error condition when reading the
control?
Or, alternatively, have a separate button control to clear the condition.
>
> Unfortunately, it only works one time, because the next time the user writes
> a zero to the control cluster_changed returns false.
>
> I think on volatile controls it is safer to run s_ctrl twice than missing a
> valid s_ctrl.
>
> I know I am abusing a bit the API for this :P, but I also believe that the
> semantic here is a bit confusing.
The reason for that is that I have yet to see a convincing argument for
allowing s_ctrl for a volatile control.
Regards,
Hans
>
> drivers/media/v4l2-core/v4l2-ctrls.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 45c5b47..3d0c7f4 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1605,7 +1605,7 @@ static int cluster_changed(struct v4l2_ctrl *master)
>
> for (i = 0; i < master->ncontrols; i++) {
> struct v4l2_ctrl *ctrl = master->cluster[i];
> - bool ctrl_changed = false;
> + bool ctrl_changed = ctrl->flags & V4L2_CTRL_FLAG_VOLATILE;
>
> if (ctrl == NULL)
> continue;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
