Thread: ohci DMA code.
Brought to you by:
aeb,
bencollins
Menu
▾
▴
linux1394-devel
|
From: Bart N. <ba...@cs...> - 2000-06-01 19:42:47
|
For those of you who are using the Ohci DMA code. Is there a way to determine if the frame in the dma buffer is valid? The DMA has a counter right, so if we have the number of bytes in one frame before a frame start we have a valid frame. I have some chopped frames one in a while, say 1/3 of the new frame and 2/3 the last frame that was on that position in the dma buffer. Are there also ideas about how multiple cameras should be handled is they are to be used with different applications? Any suggestions how to do any of this in a nice way? Thanks, Bart By the way what is the recent status of the Sony Ohci chipset? |
|
From: Daniel K. <dan...@st...> - 2000-06-02 08:43:42
|
On Thu, 1 Jun 2000, Bart Nabbe wrote: > By the way what is the recent status of the Sony Ohci chipset? I think I've been the last one so far to give that a try. But frankly, I've given up for the moment. If I hook up the Sony to an OHCI card in my desktop, the Sony shows up in gscanbus on the desktop. The upper layers in the Sony chip itself however never receive any SelfID, not even their own, and consequently the bus reset phase lasts forever. I wasn't able to find out why this is the - register dump looks good and implementations seems to be to specs. I've tried to contact Sony support for some hints but as expected no reply. Does anyone here have information that might get me further? A personal mail address of some IEEE expert with Sony maybe? Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
|
From: Sebastien R. <Seb...@sy...> - 2000-06-02 10:14:15
|
Daniel,Bart, Just a thought about the sony chipset. The laptop port has only 4 pins I believe (no power), whereas all the other cards tested so far must have 6 pins ports. In theory it should'nt change a thing, but it might worth a look (could be a slight difference in the chipset initialization maybe)... -- Sebastien Rougeaux RSISE, The Australian National University |
|
From: Matt P. <ma...@ls...> - 2000-06-02 21:21:36
|
Short answer - I wouldn't waste any time on this - it doesn't affect your driver. Long answer - From a bus function standpoint there is absolutely no difference in the 4-pin vs. 6-pin implementations. The real difference would be if power management were implemented. The power supplied via the 6-pin connector is (traditionally) not under the control of the 1394 (OHCI link or PHY) electronics. Regards, Matt Sebastien Rougeaux wrote: > Daniel,Bart, > > Just a thought about the sony chipset. The laptop port has only 4 pins > I believe (no power), whereas all the other cards tested so far must > have 6 pins ports. In theory it should'nt change a thing, but it might > worth a look (could be a slight difference in the chipset initialization > maybe)... > > -- > Sebastien Rougeaux > RSISE, The Australian National University > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- /*********************** Matt Pujol Product Marketing Manager 1394 and USB CoreWare Technologies LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
|
From: Jurgen K. <GTM...@in...> - 2000-06-08 16:06:10
|
Hi, I have bought two new PCI IEEE 1394 OHCI 1.0 complaint controllers which are not recognized by the current drivers (both CVS and kernel). The card is a Dynalink 1394P which uses a controller from Lucent Microelectronics. The vendor ID is also not recognized by the kernel so I lookup up the vendor ID at the PCI Special Interest Group but it's not there (yet?). So here are the numbers: Vendor ID: 0x11c1 Lucent Microelectronics Device ID: 0x5811 FW323 For more info: http://www.lucent.com/micro/1394/document.html FW323 Integrated OCHI Link and PHY http://www.lucent.com/micro/1394/docs/PN99156-02.pdf After modifing both ohci1394.h and ohci1394.c the cards worked so there is no problem there. Could you insert this device in your code? Thanks, Jurgen |
|
From: Sebastien R. <Seb...@sy...> - 2000-06-08 21:36:14
|
>>>>> "Jurgen" == Jurgen Kramer <GTM...@in...> writes: Jurgen> Hi, I have bought two new PCI IEEE 1394 OHCI 1.0 complaint controllers Jurgen> which are not recognized by the current drivers (both CVS and Jurgen> kernel). The card is a Dynalink 1394P which uses a controller from Jurgen> Lucent Microelectronics. The vendor ID is also not recognized by the Jurgen> kernel so I lookup up the vendor ID at the PCI Special Interest Group Jurgen> but it's not there (yet?). So here are the numbers: Jurgen> Vendor ID: 0x11c1 Lucent Microelectronics Device ID: 0x5811 FW323 Sorry for the delay, I was away. I have added the lucent chip to the list. It will be on the next CVS version. -- Sebastien Rougeaux RSISE, The Australian National University |
|
From: Matt P. <ma...@ls...> - 2000-06-02 21:17:23
|
If you're referring to a camera that adheres to the Digital Camera Spec, the best way (the only way, I think) to tell start of frame is to look at the sy bit in the isoc packet header. The driver will have to (probably optionally) pass along the sy bit to whoever is interested in capturing the frame. I think OHCI and PCILynx have the capability of starting a DMA program conditionally on the sy bit. Regards, Matt Bart Nabbe wrote: > For those of you who are using the Ohci DMA code. > > Is there a way to determine if the frame in the dma buffer is valid? The > DMA has a counter > right, so if we have the number of bytes in one frame before a frame > start we have a valid > frame. I have some chopped frames one in a while, say 1/3 of the new > frame and 2/3 the > last frame that was on that position in the dma buffer. > > Are there also ideas about how multiple cameras should be handled is > they are to be used > with different applications? > > Any suggestions how to do any of this in a nice way? > > Thanks, > > Bart > > By the way what is the recent status of the Sony Ohci chipset? > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- /*********************** Matt Pujol Product Marketing Manager 1394 and USB CoreWare technologies LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
|
From: Sebastien R. <Seb...@sy...> - 2000-06-08 22:50:00
|
>>>>> "Bart" == Bart Nabbe <ba...@cs...> writes: Bart> For those of you who are using the Ohci DMA code. Is there a way to Bart> determine if the frame in the dma buffer is valid? The DMA has a counter Bart> right, so if we have the number of bytes in one frame before a frame Bart> start we have a valid frame. I have some chopped frames one in a while, Bart> say 1/3 of the new frame and 2/3 the last frame that was on that Bart> position in the dma buffer. Bart> Are there also ideas about how multiple cameras should be handled is Bart> they are to be used with different applications? Bart> Any suggestions how to do any of this in a nice way? Currently, using /dev/ohci1394 for dma mapping, the frame interrupt is generated when the video buffer is full, and then the next video buffer starts filling up when an iso packet with the sync tag set is received. So your video frame buffer will always be full, wether or not data are lost. The way to see if a frame is good or not would be to check wether or not you discarded packets while waiting for the sync bit... I don't know if this is possible. Or maybe using timestamps of some kind. Or check wether two packets with the sync bits were inserted in the same frame... It is not on my priority list for the moment... but patch/suggestions are always welcome. -- Sebastien Rougeaux RSISE, The Australian National University |
Thanks for helping keep SourceForge clean.
X