Hi Sakari, On 07/19/2011 03:37 PM, Sakari Ailus wrote: > Hi all, > > The OMAP 3 ISP driver implements an HS_VS event which is triggered when > the reception of a frame begins. This functionality is very, very likely > not specific to OMAP 3 ISP so it should be standardised. > > I have a few patches to do that. Additionally the next expected buffer > sequence number is provided with the event, unlike earlier. > > There are a few open questions, however, and this is why I'm sending the > set as RFC. > > > 1) Other frame synchronisation events. The CCDC block in the OMAP 3 ISP > is able to trigger interrupts at two chosen lines of the image. These > naturally can be translated to events. The driver uses both of them > internally at specific points of the frame. Nevertheless, there might be > some use for these in user space. Other hardware might implement a > number of these which wouldn't be used by the driver itself, but I don't > know of that at the moment. On the other hand high resolution timers are > also available in user space, so doing timing based on ISP provided > events is not quite as important as before --- as long as there's one > frame based event produced at a known time, such as V4L2_EVENT_FRAME_START. I'm curious, have you perhaps tried to measure latency of such up calls to a user space process? I mean this is going to be a real time stuff, with HSYNC periods of 50 us order. Could a user space thread be receiving such periodic events reliably ? From my experience I doubt this can work reliably outside of an interrupt handler even with high priority real time threads. V4L2_EVENT_FRAME_START event seems OK, but HSYNC events in user space sound rather tricky to me :-) Also HS_VS looks a bit more descriptive than FRAME_START for me. But unfortunately I can't come up with a better name, e.g. something like V4L2_EVENT_FRAME_AV_START - frame active video start. Just in case in future there are more specific events added. > > Frame end events may be produced as well. This is not exactly the same > as just dequeueing the buffer at video node since the hardware may be > able to produce events even in cases there are no buffers and if the > very hardware block that processes the frame is not outputting it to > memory, handling by further blocks takes more time, and thus delays the > finishing of the buffer from the driver's queue. This is the reason why > the name of the struct related to the event is v4l2_event_frame_sync > rather than v4l2_event_frame_start. > > 2) Buffer sequence number location in the struct v4l2_event. the patches > create a new structure called v4l2_event_frame_sync which contains just > one field, buffer_sequence. Should buffer_sequence be part of this > struct, or should it be part of v4l2_event directly, as the id field? > Both buffer_sequence and id refer to another rather widely used concept > in V4L2. > > > Besides this, the first patch in the series moves the documentation of > structs inside v4l2_event to VIDIOC_DQEVENT documentation. I think it > belongs there rather than to VIDIOC_SUBSCRIBE_EVENT, since that's not > where they are being used. > -- Regards, Sylwester -- 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
