linux1394-devel Mailing List for IEEE 1394 for Linux (Page 537)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(39) |
Apr
(154) |
May
(172) |
Jun
(237) |
Jul
(127) |
Aug
(135) |
Sep
(193) |
Oct
(175) |
Nov
(173) |
Dec
(148) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(161) |
Feb
(225) |
Mar
(193) |
Apr
(158) |
May
(179) |
Jun
(292) |
Jul
(146) |
Aug
(134) |
Sep
(185) |
Oct
(190) |
Nov
(149) |
Dec
(161) |
2002 |
Jan
(186) |
Feb
(236) |
Mar
(254) |
Apr
(207) |
May
(189) |
Jun
(182) |
Jul
(202) |
Aug
(155) |
Sep
(149) |
Oct
(449) |
Nov
(191) |
Dec
(108) |
2003 |
Jan
(174) |
Feb
(242) |
Mar
(243) |
Apr
(255) |
May
(202) |
Jun
(290) |
Jul
(237) |
Aug
(178) |
Sep
(101) |
Oct
(153) |
Nov
(144) |
Dec
(95) |
2004 |
Jan
(162) |
Feb
(278) |
Mar
(282) |
Apr
(152) |
May
(127) |
Jun
(138) |
Jul
(94) |
Aug
(63) |
Sep
(64) |
Oct
(150) |
Nov
(102) |
Dec
(197) |
2005 |
Jan
(102) |
Feb
(172) |
Mar
(89) |
Apr
(158) |
May
(139) |
Jun
(160) |
Jul
(288) |
Aug
(89) |
Sep
(201) |
Oct
(92) |
Nov
(190) |
Dec
(139) |
2006 |
Jan
(121) |
Feb
(204) |
Mar
(133) |
Apr
(134) |
May
(91) |
Jun
(226) |
Jul
(122) |
Aug
(101) |
Sep
(144) |
Oct
(141) |
Nov
|
Dec
|
2023 |
Jan
(19) |
Feb
(1) |
Mar
(5) |
Apr
(5) |
May
(33) |
Jun
(17) |
Jul
|
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(40) |
2024 |
Jan
(26) |
Feb
(14) |
Mar
(26) |
Apr
(46) |
May
(17) |
Jun
(47) |
Jul
(23) |
Aug
(72) |
Sep
(33) |
Oct
|
Nov
|
Dec
|
From: Erik W. <om...@cs...> - 2000-04-19 19:47:27
|
On Wed, 19 Apr 2000, Arne Schirmacher wrote: > the extractor is already there, it is one of the little utilities that I > left in the tar file accidentally. Check it out: > http://www.schirmacher.de/arne/dvgrab/dvgrab_0.66.tar.gz . The name is > avidump.c . And of course everybody is free to use the avi library, > that's why it was GPL'ed. Hmm. I grabbed dvgrab_latest from your site and got 0.6, which is why I didn't see it. However, it seems to dump timestamps or somesuch, rather than the data. Without being more familiar with the AVI code, I'm not sure I could modify it to do so, either. > P.S. I just send a small PAL avi to Charles. OK, I'll snag a copy. I've started to add code to deal with PAL and the differences between 314M and 61834. Stay tuned. Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Arne S. <ar...@sc...> - 2000-04-19 19:39:42
|
the extractor is already there, it is one of the little utilities that I left in the tar file accidentally. Check it out: http://www.schirmacher.de/arne/dvgrab/dvgrab_0.66.tar.gz . The name is avidump.c . And of course everybody is free to use the avi library, that's why it was GPL'ed. Arne P.S. I just send a small PAL avi to Charles. -----Original Message----- From: Erik Walthinsen [SMTP:om...@cs...] Sent: Wednesday, April 19, 2000 9:18 PM To: Charles 'Buck' Krasic Cc: lin...@li... Subject: Re: libdv On 19 Apr 2000, Charles 'Buck' Krasic wrote: > > And it displays only the first frame. > This is very easy to fix. Erik should have that done shortly. Though... I don't have a working firewire setup here at home, and the only dvgrab-captured AVI file I have is bogus. If someone could send me a short (5-frame) AVI from dvgrab, I can get this working pretty quickly. Alternately, Arne seems to know best precisely what format it is and how to deal with the AVI code he's got. Perhaps it'd be easier to hack up an extractor as part of dvgrab, sharing the RIFF code? Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Erik W. <om...@cs...> - 2000-04-19 19:25:35
|
On 19 Apr 2000, Charles 'Buck' Krasic wrote: > > And it displays only the first frame. > This is very easy to fix. Erik should have that done shortly. Though... I don't have a working firewire setup here at home, and the only dvgrab-captured AVI file I have is bogus. If someone could send me a short (5-frame) AVI from dvgrab, I can get this working pretty quickly. Alternately, Arne seems to know best precisely what format it is and how to deal with the AVI code he's got. Perhaps it'd be easier to hack up an extractor as part of dvgrab, sharing the RIFF code? Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Charles 'B. K. <kr...@cs...> - 2000-04-19 19:19:18
|
Arne Schirmacher <ar...@sc...> writes: > It works only on NTSC images though. If someone were to provide us with some PAL data, we could get it working very easily indeed. PAL is one area where IEC 61834 and SMPTE 314M differ slightly. IEC 61834 uses 4:2:0 for PAL. I havn't looked to closely at that yet. SMPTE 314M uses 4:1:1, and is trivial to accomodate. > And it displays only the first frame. This is very easy to fix. Erik should have that done shortly. > Great job! > Arne Thanks! -- Buck |
From: Arne S. <ar...@sc...> - 2000-04-19 19:04:46
|
This is very cool. To display an AVI file generated by dvgrab using playdv: dd bs=1 skip=65032 if=test001.avi > test001.raw playdv test001.raw It works only on NTSC images though. And it displays only the first frame. Great job! Arne -----Original Message----- From: Charles 'Buck' Krasic [SMTP:kr...@cs...] Sent: Wednesday, April 19, 2000 4:23 PM To: Simon Vogl Cc: lin...@li... Subject: Re: xdv version 0.1 Yes, libdv does 4:1:1. See: http://libdv.sourceforge.net/ The ftp area for libdv has an NTSC bitstream file we captured with a Canon Elura. -- Buck Simon Vogl <si...@tk...> writes: > btw, does anybody have a device working with the 4:1:1 coding as > defined by the SMPTE standard? I originally wrote the decoder for > this scheme, and had a hell of a time figuing out the 4:2:0 > arrangement of the Macroblocks :) > Have fun, > Simon _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Arne S. <ar...@sc...> - 2000-04-19 19:04:45
|
neither runs or compiles on my system :-( it is just too old. I hope I'll get that SuSE 6.4 DVD real soon now Arne -----Original Message----- From: Simon Vogl [SMTP:si...@tk...] Sent: Wednesday, April 19, 2000 11:01 AM To: lin...@li... Subject: xdv version 0.1 Hi, I wrote a little utility to (partly) decode the video stream, and packed everything into a little previewer: You can get it at http://voxel.at/prj/dv/ I have tested it with PAL 4:2:0 iso streams from our Sony camcorder and our Como dv drive. I have no NTSC tapes, so I can't be sure, but it _should_ work. btw, does anybody have a device working with the 4:1:1 coding as defined by the SMPTE standard? I originally wrote the decoder for this scheme, and had a hell of a time figuing out the 4:2:0 arrangement of the Macroblocks :) Have fun, Simon _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: <Ale...@ne...> - 2000-04-19 18:53:27
|
Does anyone know if the OHCI driver supports two cards in one box? I tried to send a simple packet via a port of my choice, but only one port actually transmits the packets for both ports. More info: 1. The cards I have are the same (TI cards). 2. Each card performs well when installed alone. 3. In /proc I see that I have two cards. Thanks, Alex. |
From: Erik W. <om...@cs...> - 2000-04-19 18:30:02
|
Developers at the Systems Software Lab of the Oregon Graduate Institute are happy to announce the availability of the Quasar DV Codec (libdv), the first complete GPL'd DV decoder. libdv will currently fully decode NTSC video and display to screen via Gtk. PAL and audio aren't supported yet, but aren't too hard to do. The project can be found at http://libdv.sourceforge.net/. Sources are available from CVS only for now. Enjoy! Erik Walthinsen (Omega) Charles 'Buck' Krasic Systems Software Lab - Oregon Graduate Institute Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/ Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/ __ / \ SEUL: Simple End-User Linux - http://www.seul.org/ | | M E G A Helping Linux become THE choice _\ /_ for the home or office user |
From: Alastair M. <ala...@aj...> - 2000-04-19 16:12:56
|
Simon Vogl wrote: > > Hi, > > I wrote a little utility to (partly) decode the video stream, > and packed everything into a little previewer: You can get > it at > http://voxel.at/prj/dv/ > > I have tested it with PAL 4:2:0 iso streams from our Sony camcorder > and our Como dv drive. I have no NTSC tapes, so I can't be sure, but > it _should_ work. Great! This saves me a few hours of work. Mind you, if you'd posted it last Friday you would have saved me a few more hours of work (I started something similar over the weekend). Oh well... I'll test it with my NTSC camcorder tonight and let you know. BTW, I tried dvgrab-0.66 last night and it correctly auto-detected the stream as containing NTSC data. -- Alastair |
From: Charles 'B. K. <kr...@cs...> - 2000-04-19 14:32:08
|
Yes, libdv does 4:1:1. See: http://libdv.sourceforge.net/ The ftp area for libdv has an NTSC bitstream file we captured with a Canon Elura. -- Buck Simon Vogl <si...@tk...> writes: > btw, does anybody have a device working with the 4:1:1 coding as > defined by the SMPTE standard? I originally wrote the decoder for > this scheme, and had a hell of a time figuing out the 4:2:0 > arrangement of the Macroblocks :) > Have fun, > Simon |
From: Simon V. <si...@tk...> - 2000-04-19 09:08:45
|
Hi, I wrote a little utility to (partly) decode the video stream, and packed everything into a little previewer: You can get it at http://voxel.at/prj/dv/ I have tested it with PAL 4:2:0 iso streams from our Sony camcorder and our Como dv drive. I have no NTSC tapes, so I can't be sure, but it _should_ work. btw, does anybody have a device working with the 4:1:1 coding as defined by the SMPTE standard? I originally wrote the decoder for this scheme, and had a hell of a time figuing out the 4:2:0 arrangement of the Macroblocks :) Have fun, Simon |
From: Andreas B. <and...@mu...> - 2000-04-19 02:19:09
|
On Tue, Apr 18, 2000 at 10:58:43PM +0200, Manfred Weihs wrote: > Today I tried the bugfix of the lock transaction (ie. the cvs-version > from the last weekend) and hoped that it worked now. But I am sorry to > tell you that it still does not work. I tried a compare_swap-operaton > using a code like this: > > int errorcode=raw1394_lock(rawhandle, 0xffc0 | NodeID, > 0xfffff0000904ull, > 2, new_oPCR0, old_oPCR0, &test_oPCR0); > > (where *_PCR0 are of the type quadlet_t). > > But this does return errorcode=-1004. Does anybody know, what this > errorcode means? It means invalid arg. My fault, I had some arg checking logic in the kernel the wrong way round. Updating the subsystem to CVS should hopefully cure that problem. Maybe I should test it myself some time :-) As for the error codes: you can look them up in raw1394.h (kernel subsystem) or src/kernel-raw1394.h (libraw1394), both files are identical. Error reporting needs to be fixed (or more precisely needs a policy on what errors to return when). -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-04-18 21:07:15
|
Today I tried the bugfix of the lock transaction (ie. the cvs-version from the last weekend) and hoped that it worked now. But I am sorry to tell you that it still does not work. I tried a compare_swap-operaton using a code like this: int errorcode=raw1394_lock(rawhandle, 0xffc0 | NodeID, 0xfffff0000904ull, 2, new_oPCR0, old_oPCR0, &test_oPCR0); (where *_PCR0 are of the type quadlet_t). But this does return errorcode=-1004. Does anybody know, what this errorcode means? I have no idea. I know that node id and address are ok, because I successfully do a raw1394_read to the same position immediately before the lock. It would be nice, if somebody could help me. Manfred Weihs |
From: Alastair M. <ala...@aj...> - 2000-04-18 18:28:15
|
Mark Knecht wrote: > > Arne, > I have a Sony CCM-DC250 camera sitting here in the box unopened. It is > not a camcorder, but more of a video conferencing or security camera. Any > idea whether it will work at all with dvgrab??? I've successfully used dvgrab with my camcorder (Sony) in 'live' mode, capturing directly from the camera not the tape (without the tape even running), so my guess is that it will. -- Alastair |
From: Mark K. <mk...@co...> - 2000-04-18 17:42:14
|
Arne, I have a Sony CCM-DC250 camera sitting here in the box unopened. It is not a camcorder, but more of a video conferencing or security camera. Any idea whether it will work at all with dvgrab??? Thanks, Mark -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Tuesday, April 18, 2000 10:22 AM To: lin...@li... Subject: new dvgrab version 0.66 with tons of new cool features Hi there, download the new dvgrab version: http://www.schirmacher.de/arne/dvgrab/dvgrab_0.66.tar.gz . The most important thing is a whole new algorithm for assembling the data packets into a frame. The former algorithm simply put all packets into the frame buffer one after each other, which did not seem to work for all camcorders. This new algorithm explicitly calculates the address for each packet in the frame. I hope this will fix the scrambled images that a few users experienced. The program will try to auto-detect whether it receives PAL or NTSC format. If it doesn't work, use the former command line parameter and let me know about the problem. Finally this new version will detect the date and time of each recording and it will put it into the filename if you use the --timestamp command line parameter. Since there were several substantial changes that I could not test myself, please give this version a try. In particular if an earlier version showed garbled output, let me know whether this version fixes it. Also, if you have an NTSC camera, please check whether the auto-detect feature works with your camcorder. The HTML pages are not yet updated. I wanted to make a "Credits" section to name everybody who contributed to dvgrab, but it turned out that the list actually becomes quite long... so it is not done yet. Cheers, Arne _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Arne S. <ar...@sc...> - 2000-04-18 17:33:03
|
Hi there, download the new dvgrab version: http://www.schirmacher.de/arne/dvgrab/dvgrab_0.66.tar.gz . The most important thing is a whole new algorithm for assembling the data packets into a frame. The former algorithm simply put all packets into the frame buffer one after each other, which did not seem to work for all camcorders. This new algorithm explicitly calculates the address for each packet in the frame. I hope this will fix the scrambled images that a few users experienced. The program will try to auto-detect whether it receives PAL or NTSC format. If it doesn't work, use the former command line parameter and let me know about the problem. Finally this new version will detect the date and time of each recording and it will put it into the filename if you use the --timestamp command line parameter. Since there were several substantial changes that I could not test myself, please give this version a try. In particular if an earlier version showed garbled output, let me know whether this version fixes it. Also, if you have an NTSC camera, please check whether the auto-detect feature works with your camcorder. The HTML pages are not yet updated. I wanted to make a "Credits" section to name everybody who contributed to dvgrab, but it turned out that the list actually becomes quite long... so it is not done yet. Cheers, Arne |
From: Manfred W. <e95...@st...> - 2000-04-18 11:03:30
|
On Sat, 15 Apr 2000, Andreas Bombe wrote: > I didn't know how to size the FIFOs so I gave all of them (general > receive, async transmit, iso transmit) the same size. Try the current > version of pcilynx.c from CVS which has the iso length check already > included and configures the receive FIFO larger. I am not sure, if that was a real solution to the problem. I still get those errors, and I think, they come as frequently as before. Manfred Weihs |
From: Simon V. <si...@tk...> - 2000-04-18 10:54:05
|
Hi all, I am currently toying around with decoding DV video data, but seem to have serious problems regarding the placement of the decoded macro-blocks. I do have the smpte 314M standard, which is a great help, but something seems still wrong: the position of the macroblocks inside the superblocks seem to be incorrect, b/w edges are doubled (within the superblocks only, though), or vanish partly. I found out that my Sony camera codes video in IEC-61834 (the APT fields are 000), but I do not have these specs - could anybody tell me how the mbs are aligned there? Thanks, Simon |
From: Wildcat <ca...@dc...> - 2000-04-18 09:54:22
|
Hello, I have a Western Digital Fire Wire hard drive, iI would be interested in being a tester for the ieee1394 to get it running under Linux. Please reply if anyone would be interested in providing the code for it. Earl Brown |
From: Olivier L. <la...@cy...> - 2000-04-18 05:47:00
|
Hello, I'm new to this list. My programmer kernel knowledge is near /dev/null, but I know a "little" in C programming. Anyway I can help by testing, because I have a Pinnacle DV500 Video Edition that has a firewire controler with 3 ports (2 externals, 1 internal) on board. I've just tested kernel 2.3.99-pre5 I insmoded the core, the ohci and the raw ieee1394 modules. Everything seems ok, but as I don't know the state of the project I don't know what the driver is able to. My Fire wire peripherals are: 1 LaCie 20GB Hard drive (in fact it seems to be a 7200RPM IDE Drive with firewire controler attached to it). Maybe this controler is a firewire IDE controler... My other peripheral is: 1 Camcorder JVC DVL9600. I didn't compiled with debug (for the fists tests, but I'll do it soon). Connecting the HD gives me 1 line telling me something is ignored (but as I am under windows, i can't tell this now) Connecting the camcorder gives me some groups of messages composed of approx. 5 or 6 lines. Please can you tell me what infos I should give? /proc/ieee1394 ? dmesg? What is needed for now? Many thanks for answers. Please tell me if this is not the good mailing list (as I'm not developper, just a potential tester). Greetings, -- Olivier LAHAYE |
From: Andreas B. <and...@mu...> - 2000-04-17 17:32:08
|
On Sun, Apr 16, 2000 at 05:48:16PM +0300, And...@no... wrote: > > That is a possibility, but probably not in libraw's code. The > > raw1394_stop_iso_rcv() sends the stop request to the kernel and then > > loops on raw1394_loop_iterate() until it sees the response. During > > that handlers will be called for all remaining (e.g. iso) packets. > > Oh, I see. I thought that packets coming in during execution of > raw1394_stop_iso_recv() was discarded. This should perhaps be mentioned in > raw1394.h. I will write some real documentation once I have the more immediate ToDo's implemented. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-04-17 17:31:07
|
On Sun, Apr 16, 2000 at 09:24:13PM -0700, Jeff Mak wrote: > Sebastien > > As you are the writer of OHCI driver, I think you are the best one in > answering my queries: > > I am making use of raw1394 (dev_open) to connect to the other node through > OHCI kernel driver, when there is a change in power status at PHY of the > other node, a bus reset would be generated from the hardware. Is it true > that the connection in between would be lost? In other words, can I send > any other command to the target node using the same handle? Yes. You can register a bus reset handler with the libraw handle and should do so if you need to find out whenever something changes. I'm currently working on GUID collection and using that for requests, but I don't think this applies to your problem. > The reason why I ask this question is: I am currently trying to talk to a > target node which has a "wake up" feature. In other words, if the target > node is idle for period of time, it will try to shutdown itself until it > receives a "wake up" command from my linux box. However, when the target > node is idle and auto shutoff. Bus reset would be generated causing I > cannot get the respond from the target node anymore using the same > raw1394_handle. If the target has its link layer shut down (I guess it has) it can not process any requests. It needs a link-on phy packet. Sending phy packets is not implemented yet. > I have tried to deactivate the bus reset event on > interrupt of OHCI driver but it is not working. I believe deactivating the > interrupt event mask on bus reset is just ignore the bus reset on kernel > driver side. Ignoring a bus reset can only cause harm and will not help you there. > I suppose if the target node get the power from the firewire bus and my > firewire card is a power supplier, there shouldn't be any bus reset even if > the target node is in power off mode. Is my understanding correct? I > know that this is IEEE1394 specific and if you have any suggestion, please > let me know. A bus reset is created whenever a node is added, removed, powered up or powered down. Anything that would change SelfID information, in short. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Jeff M. <Jef...@ef...> - 2000-04-17 06:20:28
|
Sebastien, Thanks for prompt response. Yes, the bus reset signal would generate whenever the target node is in "sleep" mode. Jeff -----Original Message----- From: Sebastien Rougeaux [mailto:Seb...@sy...] Sent: Sunday, April 16, 2000 9:52 PM To: Jef...@ef... Cc: lin...@li... Subject: Re: Bus Reset >>>>> "Jeff" == Jeff Mak <Jef...@ef...> writes: Jeff> I am making use of raw1394 (dev_open) to connect to the other node Jeff> through OHCI kernel driver, when there is a change in power status at Jeff> PHY of the other node, a bus reset would be generated from the hardware. Jeff> Is it true that the connection in between would be lost? In other Jeff> words, can I send any other command to the target node using the same Jeff> handle? I know that this is not OHCI specific question but since I am Jeff> using OHCI kernel driver written by you, I believe you may have some Jeff> experience on that. I don't think bus reset are handled properly yet in the current version of the linux ieee1394 driver. If a bus reset occurs, the node numbers on the bus are re-assigned, and I don't think that libraw is designed to deal with that situation (I might be wrong though). Especially, the ohci driver receives a specific phy packet that indicates precisely when the bus configuration has been modified, but this packet is currently being discarded since the subsystem doesn't accept it... I have to talk to Andreas about that. Jeff> The reason why I ask this question is: I am currently trying to talk to Jeff> a target node which has a "wake up" feature. In other words, if the Jeff> target node is idle for period of time, it will try to shutdown itself Jeff> until it receives a "wake up" command from my linux box. However, when Jeff> the target node is idle and auto shutoff. Bus reset would be generated Jeff> causing I cannot get the respond from the target node anymore using the Jeff> same raw1394_handle. I have tried to deactivate the bus reset event on Jeff> interrupt of OHCI driver but it is not working. I believe deactivating Jeff> the interrupt event mask on bus reset is just ignore the bus reset on Jeff> kernel driver side. Do you mean that everytime the node goes in 'sleep' mode, a bus reset is generated ??? Jeff> I suppose if the target node get the power from the firewire bus and my Jeff> firewire card is a power supplier, there shouldn't be any bus reset even Jeff> if the target node is in power off mode. Is my understanding correct? Jeff> I know that this is IEEE1394 specific and if you have any suggestion, Jeff> please let me know. Sorry I don't know about that particular point of the ieee1394 standard. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-17 04:57:57
|
>>>>> "Jeff" == Jeff Mak <Jef...@ef...> writes: Jeff> I am making use of raw1394 (dev_open) to connect to the other node Jeff> through OHCI kernel driver, when there is a change in power status at Jeff> PHY of the other node, a bus reset would be generated from the hardware. Jeff> Is it true that the connection in between would be lost? In other Jeff> words, can I send any other command to the target node using the same Jeff> handle? I know that this is not OHCI specific question but since I am Jeff> using OHCI kernel driver written by you, I believe you may have some Jeff> experience on that. I don't think bus reset are handled properly yet in the current version of the linux ieee1394 driver. If a bus reset occurs, the node numbers on the bus are re-assigned, and I don't think that libraw is designed to deal with that situation (I might be wrong though). Especially, the ohci driver receives a specific phy packet that indicates precisely when the bus configuration has been modified, but this packet is currently being discarded since the subsystem doesn't accept it... I have to talk to Andreas about that. Jeff> The reason why I ask this question is: I am currently trying to talk to Jeff> a target node which has a "wake up" feature. In other words, if the Jeff> target node is idle for period of time, it will try to shutdown itself Jeff> until it receives a "wake up" command from my linux box. However, when Jeff> the target node is idle and auto shutoff. Bus reset would be generated Jeff> causing I cannot get the respond from the target node anymore using the Jeff> same raw1394_handle. I have tried to deactivate the bus reset event on Jeff> interrupt of OHCI driver but it is not working. I believe deactivating Jeff> the interrupt event mask on bus reset is just ignore the bus reset on Jeff> kernel driver side. Do you mean that everytime the node goes in 'sleep' mode, a bus reset is generated ??? Jeff> I suppose if the target node get the power from the firewire bus and my Jeff> firewire card is a power supplier, there shouldn't be any bus reset even Jeff> if the target node is in power off mode. Is my understanding correct? Jeff> I know that this is IEEE1394 specific and if you have any suggestion, Jeff> please let me know. Sorry I don't know about that particular point of the ieee1394 standard. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Jeff M. <Jef...@ef...> - 2000-04-17 04:31:36
|
Sebastien As you are the writer of OHCI driver, I think you are the best one in answering my queries: I am making use of raw1394 (dev_open) to connect to the other node through OHCI kernel driver, when there is a change in power status at PHY of the other node, a bus reset would be generated from the hardware. Is it true that the connection in between would be lost? In other words, can I send any other command to the target node using the same handle? I know that this is not OHCI specific question but since I am using OHCI kernel driver written by you, I believe you may have some experience on that. The reason why I ask this question is: I am currently trying to talk to a target node which has a "wake up" feature. In other words, if the target node is idle for period of time, it will try to shutdown itself until it receives a "wake up" command from my linux box. However, when the target node is idle and auto shutoff. Bus reset would be generated causing I cannot get the respond from the target node anymore using the same raw1394_handle. I have tried to deactivate the bus reset event on interrupt of OHCI driver but it is not working. I believe deactivating the interrupt event mask on bus reset is just ignore the bus reset on kernel driver side. I suppose if the target node get the power from the firewire bus and my firewire card is a power supplier, there shouldn't be any bus reset even if the target node is in power off mode. Is my understanding correct? I know that this is IEEE1394 specific and if you have any suggestion, please let me know. Cheers, Jeff |