Re: updated dma to user space API
Brought to you by:
aeb,
bencollins
From: Manfred W. <e95...@st...> - 2000-05-02 21:25:44
|
Sebastien Rougeaux wrote: > The important part for me > is that the driver: > > . allows multi-buffering (tunable) > . doesn't waste CPU time > . does frame synchronization Of course not wasting CPU time is a very important topic concerning the reception of iso packets. But in the last issue (frame synchronisation) I do not aggree with you. That should not be done by the driver; any interpretation of the content of an iso packet should be done by the application. The driver shall deliver the raw packets (as libraw does now) and the application should decide, what the data is and whether it has to look for sync tags and things like that. One reason is, that there are many different data types transmitted via isochronous channels, not only plain video images. For example I receive MPEG 2 transport streams, and I want to get the packets as they are, the driver shall not interpret them. The only extension I could imagine is, that the driver could resolve the CIP-format (ie. Reassembling the source packets and either forwarding them to the application, when the time stamp [in the source packet header; that correspond to the least significant bytes of the 16 bits of the cycle time register] is reached or forwarding them immediately together with the timestamp); all further interpretation is up to the application. I believe, the interface for receiving iso packets, which libraw provides, is good. The only thing that might be changed is handling of the header; I already mentioned that byte-swapping would make sense for consistency. Of course the "low-level-handling" of these packets in the driver could (should) be optimated, but the interface in libraw should stay unchanged. Manfred Weihs PS: Did somebody read my posting about using the cycle time register for synchronisation (my whishlist entry)? Any comments? |