S_CTRL must be called twice to set volatile controls

S_CTRL must be called twice to set volatile controls

[Jacek Anaszewski]

Hi,

After testing my v4l2-flash helpers patch [1] with the recent patches
for v4l2-ctrl.c ([2] and [3]) s_ctrl op isn't called despite setting
the value that should be aligned to the other step than default one.

This happens for V4L2_CID_FLASH_TORCH_INTENSITY control with
V4L2_CTRL_FLAG_VOLATILE flag.

The situation improves after setting V4L2_CTRL_FLAG_EXECUTE_ON_WRITE
flag for the control. Is this flag required now for volatile controls
to be writable?

[1] http://www.spinics.net/lists/linux-media/msg89004.html
[2] 45f014c5 [media] media/v4l2-ctrls: Always execute EXECUTE_ON_WRITE ctrls
[3] b08d8d26 [media] media/v4l2-ctrls: volatiles should not generate 
CH_VALUE
-- 
Best Regards,
Jacek Anaszewski

Re: S_CTRL must be called twice to set volatile controls

[Hans Verkuil]

Hi Jacek,

On 04/29/15 09:33, Jacek Anaszewski wrote:
> Hi,
> 
> After testing my v4l2-flash helpers patch [1] with the recent patches
> for v4l2-ctrl.c ([2] and [3]) s_ctrl op isn't called despite setting
> the value that should be aligned to the other step than default one.
> 
> This happens for V4L2_CID_FLASH_TORCH_INTENSITY control with
> V4L2_CTRL_FLAG_VOLATILE flag.
> 
> The situation improves after setting V4L2_CTRL_FLAG_EXECUTE_ON_WRITE
> flag for the control. Is this flag required now for volatile controls
> to be writable?

Yes, you need that if you want to be able to write to a volatile control.

It was added for exactly that purpose.

Why is V4L2_CID_FLASH_TORCH_INTENSITY volatile? Volatile typically only
makes sense if the hardware itself is modifying the value without the
software knowing about it.

Regards,

	Hans

> 
> [1] http://www.spinics.net/lists/linux-media/msg89004.html
> [2] 45f014c5 [media] media/v4l2-ctrls: Always execute EXECUTE_ON_WRITE ctrls
> [3] b08d8d26 [media] media/v4l2-ctrls: volatiles should not generate CH_VALUE

Re: S_CTRL must be called twice to set volatile controls

[Jacek Anaszewski]

Hi Hans,

On 04/29/2015 09:53 AM, Hans Verkuil wrote:
> Hi Jacek,
>
> On 04/29/15 09:33, Jacek Anaszewski wrote:
>> Hi,
>>
>> After testing my v4l2-flash helpers patch [1] with the recent patches
>> for v4l2-ctrl.c ([2] and [3]) s_ctrl op isn't called despite setting
>> the value that should be aligned to the other step than default one.
>>
>> This happens for V4L2_CID_FLASH_TORCH_INTENSITY control with
>> V4L2_CTRL_FLAG_VOLATILE flag.
>>
>> The situation improves after setting V4L2_CTRL_FLAG_EXECUTE_ON_WRITE
>> flag for the control. Is this flag required now for volatile controls
>> to be writable?
>
> Yes, you need that if you want to be able to write to a volatile control.
>
> It was added for exactly that purpose.

Thanks for the explanation.

> Why is V4L2_CID_FLASH_TORCH_INTENSITY volatile? Volatile typically only
> makes sense if the hardware itself is modifying the value without the
> software knowing about it.

This can be the case for the flash LED devices that can reduce torch
current when battery voltage level falls below predefined threshold.

-- 
Best Regards,
Jacek Anaszewski

Re: S_CTRL must be called twice to set volatile controls

[Sakari Ailus]

Hi Jacek,

On Wed, Apr 29, 2015 at 10:58:20AM +0200, Jacek Anaszewski wrote:
> Hi Hans,
> 
> On 04/29/2015 09:53 AM, Hans Verkuil wrote:
> >Hi Jacek,
> >
> >On 04/29/15 09:33, Jacek Anaszewski wrote:
> >>Hi,
> >>
> >>After testing my v4l2-flash helpers patch [1] with the recent patches
> >>for v4l2-ctrl.c ([2] and [3]) s_ctrl op isn't called despite setting
> >>the value that should be aligned to the other step than default one.
> >>
> >>This happens for V4L2_CID_FLASH_TORCH_INTENSITY control with
> >>V4L2_CTRL_FLAG_VOLATILE flag.
> >>
> >>The situation improves after setting V4L2_CTRL_FLAG_EXECUTE_ON_WRITE
> >>flag for the control. Is this flag required now for volatile controls
> >>to be writable?
> >
> >Yes, you need that if you want to be able to write to a volatile control.
> >
> >It was added for exactly that purpose.
> 
> Thanks for the explanation.
> 
> >Why is V4L2_CID_FLASH_TORCH_INTENSITY volatile? Volatile typically only
> >makes sense if the hardware itself is modifying the value without the
> >software knowing about it.
> 
> This can be the case for the flash LED devices that can reduce torch
> current when battery voltage level falls below predefined threshold.

Can the LED flash actually tell about this, other than reading this through
the faults? I don't know of a LED flash that could do this, so I wonder if
we could make these controls non-volatile, as the reason I originally though
why they were volatile (the V4L2 control framework being more or less just a
front-end) was not a valid one.

I guess this could be done later on on top of the patch you currently have.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: S_CTRL must be called twice to set volatile controls

[Jacek Anaszewski]

Hi Sakari,

On 04/29/2015 02:01 PM, Sakari Ailus wrote:
> Hi Jacek,
>
> On Wed, Apr 29, 2015 at 10:58:20AM +0200, Jacek Anaszewski wrote:
>> Hi Hans,
>>
>> On 04/29/2015 09:53 AM, Hans Verkuil wrote:
>>> Hi Jacek,
>>>
>>> On 04/29/15 09:33, Jacek Anaszewski wrote:
>>>> Hi,
>>>>
>>>> After testing my v4l2-flash helpers patch [1] with the recent patches
>>>> for v4l2-ctrl.c ([2] and [3]) s_ctrl op isn't called despite setting
>>>> the value that should be aligned to the other step than default one.
>>>>
>>>> This happens for V4L2_CID_FLASH_TORCH_INTENSITY control with
>>>> V4L2_CTRL_FLAG_VOLATILE flag.
>>>>
>>>> The situation improves after setting V4L2_CTRL_FLAG_EXECUTE_ON_WRITE
>>>> flag for the control. Is this flag required now for volatile controls
>>>> to be writable?
>>>
>>> Yes, you need that if you want to be able to write to a volatile control.
>>>
>>> It was added for exactly that purpose.
>>
>> Thanks for the explanation.
>>
>>> Why is V4L2_CID_FLASH_TORCH_INTENSITY volatile? Volatile typically only
>>> makes sense if the hardware itself is modifying the value without the
>>> software knowing about it.
>>
>> This can be the case for the flash LED devices that can reduce torch
>> current when battery voltage level falls below predefined threshold.
>
> Can the LED flash actually tell about this, other than reading this through
> the faults?

MAX77693-flash device supports this.

> I don't know of a LED flash that could do this, so I wonder if
> we could make these controls non-volatile, as the reason I originally though
> why they were volatile (the V4L2 control framework being more or less just a
> front-end) was not a valid one.

The other reason for keeping the controls volatile is the fact that
LED subsystem has brightness_get op, which can be implemented by
drivers to report the current level actually set.

> I guess this could be done later on on top of the patch you currently have.
>


-- 
Best Regards,
Jacek Anaszewski