Thread: RE: updated dma to user space API
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-devel
|
From: <And...@no...> - 2000-05-10 07:59:15
|
> > Sebastien Rougeaux wrote: > > The important part for me > > is that the driver: > > > > . allows multi-buffering (tunable) > > . doesn't waste CPU time > > . does frame synchronization > Manfred Weihs wrote: > 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. I also think that interpretations of iso packets should be left to the application. The 1394 driver should only address 1394 related issues, not application specific stuff such as reception of isochronous DV streams. DV is the most important usage for isochronous transfers today but we will most likely see a lot of new things in the future. The best thing to do, I think, is to keep the driver as clean as possible and conentrate on having it up to date with the development of 1394. Keep up the good work everyone! Regards, Anders Weitman |
|
From: Jun S. <jul...@ya...> - 2000-04-25 17:20:41
|
> > NOTE 1: the driver is probably not safe for SMP > machines (will do that > later). It might also not be wise to share the > device /dev/ohci1394 > between several threads/processes. > I am lost a little bit. How does this driver relate to libraw? As a separate question, can the libraw be shared by multiple processes or multiple threads? If the answer is yes, I wonder if any behavior is modified. For example, if both processes listen for the same iso channel, will they both get the data? Thanks. Jun __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com |
|
From: Andreas B. <and...@mu...> - 2000-04-25 19:56:02
|
On Tue, Apr 25, 2000 at 10:12:24AM -0700, Jun Sun wrote: > > > > > NOTE 1: the driver is probably not safe for SMP > > machines (will do that > > later). It might also not be wise to share the > > device /dev/ohci1394 > > between several threads/processes. > > > > I am lost a little bit. How does this driver relate > to libraw? libraw doesn't yet have zero copy of iso packets. > As a separate question, can the libraw be shared by > multiple processes or multiple threads? One libraw1394 handle must not be shared by multiple processes or threads, apart from that it can be used in multithreaded programs. > If the answer is yes, I wonder if any behavior is > modified. For example, if both processes listen for > the same iso channel, will they both get the data? Yes. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
|
From: Sebastien R. <Seb...@sy...> - 2000-04-25 23:20:47
|
>>>>> "Jun" == Jun Sun <jul...@ya...> writes: >> NOTE 1: the driver is probably not safe for SMP machines (will do that >> later). It might also not be wise to share the device /dev/ohci1394 between >> several threads/processes. >> Jun> I am lost a little bit. How does this driver relate to libraw? The direct dma to user space feature bypass libraw (at least for the moment). So you use libraw to send 1394 commands to your camera, and you use the /dev/ohci1394 device to initialize/receive video frames. Jun> If the answer is yes, I wonder if any behavior is modified. For example, Jun> if both processes listen for the same iso channel, will they both get the Jun> data? If you use libraw to get iso data, then I guess yes data are duplicated. For direct iso-dma to user space, no. A same Iso channel cannot be listened by two separate dma contexts (except if you have 2 cards in the box I think), so there can be only one destination in memory for one iso channel. -- Sebastien Rougeaux RSISE, The Australian National University |
|
From: Sebastien R. <Seb...@sy...> - 2000-05-11 04:46:13
|
>>>>> "Anders" == Anders Weitman <And...@no...> writes: >> Manfred Weihs wrote: 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. Anders> I also think that interpretations of iso packets should be left to the Anders> application. The 1394 driver should only address 1394 related issues, Anders> not application specific stuff such as reception of isochronous DV Anders> streams. DV is the most important usage for isochronous transfers Anders> today but we will most likely see a lot of new things in the Anders> future. The best thing to do, I think, is to keep the driver as clean Anders> as possible and conentrate on having it up to date with the Anders> development of 1394. What I had in mind is a frame grabber driver... of course we can think of a more low-level iso receive driver (in fact just removing the sync tag in my current iso receive driver would probably work for more general iso reception). -- Sebastien Rougeaux RSISE, The Australian National University |
Thanks for helping keep SourceForge clean.
X