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
--
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
