Hello Hans I need to figure out how can you reply that fast. Thanks a lot! On Tue, Feb 17, 2015 at 12:17 PM, Hans Verkuil <hansverk@xxxxxxxxx> wrote: >> 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 control exposes a bit on the trigger system. The application polls it at its own rate. I could convince the hardware engineer to make an inq on that event, but right now the hw does not support it. > >> 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? There might be two applications running at the same time. ie: APP1 calibrates the camera, while APP2 gets images. APP1 will ack the error and APP2 will never notice, when is APP2 the one that cares abot the error. > > Or, alternatively, have a separate button control to clear the condition. > Of course this is an option, but I think this is not very clean. >> 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. This kind of error flags could be a nice candidate for this control. Right now we can create a volatile control with s_ctrl, the api allows it, so I think it is either not allowing that or adding this patch. Both are perfectly fine :), but allowing s_ctrl and volatile and then now running s_ctrl always seems a bit weird to me. Thanks! -- Ricardo Ribalda -- 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
