linux1394-devel Mailing List for IEEE 1394 for Linux (Page 532)
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: Bruce M. <br...@tr...> - 2000-05-14 13:53:14
|
All, I have completed the first release of libavc1394. Sorry about the delay but one thing led to another... you know how it goes ;) Well, anyway download it from the url below. Note that it is completely undocumented - so use the source. The functions available are listed in avc.h. (not working now) http://home.triphop.org:8080/~bruce/libavc1394-0.0.1.tar.gz (working) http://home.carolina.rr.com/triphop/libavc1394-0.0.1.tar.gz I am trying to get the timecode code working - please test (run testavc) on your equipment (don't worry it does not record!). Bruce. PS. I will be RPMizing this library - is there anyone doing this for libraw1394 or should I be doing this one too. |
From: Sebastien R. <Seb...@sy...> - 2000-05-14 02:08:44
|
>>>>> "Daniel" == Daniel Kobras <dan...@st...> writes: Daniel> Hi Sebastien! The OHCI irq handler uses reg_read() to determine Daniel> whether it has to service an interrupt. reg_read() in turn relies on ohci-> registers containing the controllers remapped MMIO Daniel> space. add_card() however requests the irq long before the ioremap(), Daniel> thus leaving a window open where we might access bogus memory Daniel> locations. The race should only occur if the irq line is shared with Daniel> other devices. Patch below that moves request_irq() to the very end of Daniel> add_card(). Thanks for the patch. Any luck with the SONY chip ? -- Sebastien Rougeaux RSISE, The Australian National University |
From: Daniel K. <dan...@st...> - 2000-05-13 16:28:32
|
Hi Sebastien! The OHCI irq handler uses reg_read() to determine whether it has to service an interrupt. reg_read() in turn relies on ohci->registers containing the controllers remapped MMIO space. add_card() however requests the irq long before the ioremap(), thus leaving a window open where we might access bogus memory locations. The race should only occur if the irq line is shared with other devices. Patch below that moves request_irq() to the very end of add_card(). Regards, Daniel. --[snip]-- Index: ohci1394.c =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v retrieving revision 1.28 diff -u -r1.28 ohci1394.c --- ohci1394.c 2000/05/12 02:16:07 1.28 +++ ohci1394.c 2000/05/13 16:09:14 @@ -2185,13 +2185,6 @@ ohci->state = 0; - if (!request_irq(dev->irq, ohci_irq_handler, SA_SHIRQ, - OHCI1394_DRIVER_NAME, ohci)) { - PRINT(KERN_INFO, ohci->id, "allocated interrupt %d", dev->irq); - } else { - FAIL("failed to allocate shared interrupt %d", dev->irq); - } - /* csr_config rom allocation */ ohci->csr_config_rom = kmalloc(1024, GFP_KERNEL); if (ohci->csr_config_rom == NULL) { @@ -2269,6 +2262,13 @@ PRINT(KERN_INFO, ohci->id, "remapped memory spaces reg 0x%p", ohci->registers); + + if (!request_irq(dev->irq, ohci_irq_handler, SA_SHIRQ, + OHCI1394_DRIVER_NAME, ohci)) { + PRINT(KERN_INFO, ohci->id, "allocated interrupt %d", dev->irq); + } else { + FAIL("failed to allocate shared interrupt %d", dev->irq); + } return 0; #undef FAIL |
From: Bruce M. <br...@tr...> - 2000-05-13 03:31:02
|
All, I have completed the first release of libavc1394. Sorry about the delay but one thing led to another... you know how it goes ;) Well, anyway download it from the url below. Note that it is completely undocumented - so use the source. The functions available are listed in avc.h. (not working now) http://home.triphop.org:8080/~bruce/libavc1394-0.0.1.tar.gz (working) http://home.carolina.rr.com/triphop/libavc1394-0.0.1.tar.gz I am trying to get the timecode code working - please test (run testavc) on your equipment (don't worry it does not record!). Bruce. |
From: Andreas B. <and...@mu...> - 2000-05-12 23:36:11
|
On Thu, May 11, 2000 at 04:34:48PM +0200, lin...@li... wrote: > Hi, > > On Thu, May 11, 2000 at 04:11:07PM +0200, Franck Bonin wrote: > > So I have tryed to transform my PC-linux in an > > TapeRecorderPlayer and > > today I have succeded, by re-writing the ohci_csr_rom > > located in the ohci1394.h file. [...] > I would also like to see this thing run on an unmodofied Linux kernel. We > would need an interface for changing the CSR ROM at run time, oder maybe the > driver module should read the CSR rom from a file. The filename could be > specified at module loading time as an optional parameter. What do the driver > maintainers think of this idea? Reading from a file is not a good idea (reading a config file from kernel is not good and requires the kernel to know the file path). Dynamically creating the CSR ROM is a good idea however. We'd need some functions to create the ROM from an arbitrary number of info blocks. The header and bus info block is simple, the following root directory should be created on the fly from block info. The 1394 standard I have here doesn't give really detailed information on that, instead it references ISO/IEC 13213: 1994. Anyone wants to write support for that? Shouldn't be too hard if you know the exact implementation of CSR ROMs. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-05-12 23:35:38
|
On Tue, May 09, 2000 at 06:20:55PM +0300, And...@no... wrote: > Hi, > > Do you know the amount of memory that the Linux 1394 subsystem will require? > Right now the three modules (ieee1394, ohci1394 and raw1394) use about 30k > (according to lsmod). More important is perhaps how much memory is allocated > for variables, structs, buffers etc. during operation? I guess this is > depending on the number of nodes so it should probable be specified in terms > of x bytes/node. The initial allocation is indeed per local node. I don't have the numbers handy, but it's sizeof(struct hpsb_host) + sizeof(hardware driver control struct). Highlevel drivers also need structs (per driver not per local node), allocation is sizeof(struct hpsb_highlevel) + n*sizeof(struct hpsb_address_serve) where n is the number of distinct address spaces. PCILynx additionally allocates 64kB for DMA control structures. These 64kB are in no way fully used, the 64kB comes from the fact that the local RAM interface of the Lynx supports 64kB of RAM for such structures but this is emulated in main memory since most boards don't have local RAM. It should be sized down to the really used amount, currently it's wasted. That's PCILynx only. After that comes dynamic allocation for packets and that depends on bus traffic. For each transaction a struct hpsb_packet is allocated + fixed 20 bytes for 1394 header + the max of however much 1394 data is required for sending or receiving. For incoming requests these are kept until the response is sent. Outgoing requests are kept until they are freed by whatever sent it (earliest either after sending or, for split transactions, after response is received). Iso receive through raw1394 stores packets up to a fixed limit. Failure to allocate loses current frames. This is only the intermediate implementation, what I have in mind is something more sophisticated that drops old packets when memory is low. The initial allocations shouldn't be too heavy, the dynamic allocations account for most when traffic to/from bus is heavy. It should be possible to take some stats for async transactions since they all go through (alloc|free)_hpsb_packet() where some code could record usage data. The other big allocation point is the raw1394 iso receive function. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-05-12 23:35:24
|
On Tue, May 09, 2000 at 04:32:37PM -0400, Olivier Daigle wrote: > Hi Ashok, > I managed to exchange raw data between 2 computers by using an FCP-like > method and libraw1394. Mainly, I copied FCP code and extended it to allow data > being transferred by chunks of 2k (instead of 512 bytes with bare FCP code). > This was pretty easy. Problem is: there is a long delay between every data > transfer and even with fast machines (Pentium III 450MHz) and I can't manage to > get data transferred faster than 2.5 Mbytes/sec. By using Frank Bonin's > implementation of IP-over-1394 (which use async transactions), I can > ftp-transfer as fast as 15Mbytes/sec with slow machines (pentium 200MMX) so I > guess I should be able to do as fast as him... Depends on how you implemented the transfer protocol. FCP is more expensive since request and response are each full 1394 write transactions consisting of request and response packets themselves, theoretically this makes FCP take up twice as much packets as low level transactions. Have you tried to minimize the requests? Don't require responses for every FCP write but only for every dozen or so (which contains the individual responses all at once) and a response on timeout (in case not enough packets are around). This should enhance throughput (but might decrease responsiveness a little since responses might be delayed). Additionally, at a lower level, you can also send out multiple packets without waiting for the hardware to actually do it. Use raw1394_start_write() without raw1394_loop_iterate() after each packet. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Matt P. <ma...@ls...> - 2000-05-12 18:13:58
|
It may help to modify the config ROM to look like a camera instead of a PC. Matt Franck Bonin wrote: > I have fix some Pbs with my virtal_VCR, by using the > last dvgrab > version 0.7 with a patch that can output files for > playdv (last > version). The movie is good (I can finally reconize > the dog). But playdv crash > at the end of the movie (segmentation fault), here is > the error > output : > > ** CRITICAL **: file bitstream.h: line 155 > (bitstream_unget): > assertion `(num_bits <= 32) && (num_bits >0) && > (!(data & (~mask)))' > failed. > > Since xdv0.1 does not correctly decode my isochrone > flow, I > will try to build a direct line movie player which > will use dvgrab's > --dv algorithms option and the libdv codecs. > > Currently, I have a ROM for IEEE 1394 boards. I have a > small program > that listen to FCP commands and try to respond like a > VCR > does. (Probably soon avaible) > > But I do not support yet all commands described in the > AV/C Tape > Recorder / Player Subunit Specification. > > In fact, I do not now exactly what is meaning of some > commands. > And what are the main commands to support. > > --- > > Franck Bonin > > --- Andreas Micklei a écrit : > Hi, > > > > On Thu, May 11, 2000 at 04:11:07PM +0200, Franck > > Bonin wrote: > > > So I have tryed to transform my PC-linux in an > > > TapeRecorderPlayer and > > > today I have succeded, by re-writing the > > ohci_csr_rom > > > located in the ohci1394.h file. > > > > That is great. Right now I use the Linux 1394 > > subsystem mainly for controlling > > a digital VCR. A virtual VCR on another Linux host > > would provide the perfect > > debugging tool for testing all those optional > > features that real VCRs do not > > implement yet. > > > > If you have some more specific questions, feel free > > to ask. You can also send > > me your source if you like. > > > > I would also like to see this thing run on an > > unmodofied Linux kernel. We > > would need an interface for changing the CSR ROM at > > run time, oder maybe the > > driver module should read the CSR rom from a file. > > The filename could be > > specified at module loading time as an optional > > parameter. What do the driver > > maintainers think of this idea? > > > > bye... > > Andreas Micklei > > > > ___________________________________________________________ > Do You Yahoo!? > Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr > > _______________________________________________ > 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: Daniel K. <dan...@st...> - 2000-05-12 18:09:05
|
On Thu, 11 May 2000, Sebastien Rougeaux wrote: [That's still about getting CXD3222 chips to work with ohci1394.o] > Could you please add a debug message at the top of the irq handler, > and verify that the irq handler is called when the driver is loaded. Taking today's ohci driver from CVS, I've run a few more tests in the meantime with more debugging output enabled. In particular I've added code to the irq handler that shows the contents of the IntEvent register masked and unmasked (raw), and the current mask itself. As you proposed, I also included a loop at the beginning of the irq handler to wait for NodeID to become valid. Each cycle has a suckin' udelay(10) in it, but hey, it's only for debugging. The good news is that with those two additions I actually see several PHY packets arriving. Even better, I see PHY activity when switching on and off the camcorder attached to the Vaio. The downside is that still I couldn't figure out how to convince the CXD3222 to handle some selfIDs. As an aside, even though the driver will now properly shut down the chipset when it is removed, a rmmod-insmod cycle without any other activity will inevitably hang the whole machine to the point where Alt-SysRq-b seems to be the only working key combination. I first suspected the irq handler but a few tests proved its innocence. I've never fiddled that much with DMA stuff before and am unsure if a misconfiguration there might lock a machine. Actually I had similar symptoms with an el-cheapo network card that was very picky about the way its MMIO PCI registers were accessed and would eventually mess up the whole PCI bus. Does anyone know of subtle access restrictions regarding the OHCI/IEEE registers? > You should have something like this after `insmod ohci1394` > > ........ > ohci1394_0: resetting bus on request and attempting to become root > ieee1394: detected 1 ohci1394 adapter > ohci1394_0: IntEvent: 00020010 > ohci1394_0: IntEvent: 00020000 > ohci1394_0: IntEvent: 00020000 > ....... Is this a true sequence you see or did you just leave out the null events? In section 6.1.1 of the OHCI specs it says that the controller is supposed to prevent the driver from clearing the bus reset bit until selfIDComplete is flagged, whereas the CXD3222 seems to happily take the ack. I've modified the irq handler to mask busReset and postpone the ack until reception of selfIDComplete in this case but wasn't really successful. Below I've attached a pile of debugging output - maybe some of the OHCI wizards can have a look at it and give me some more hints on what to try next to get this beast going. I'm now off for another night on the specs. Regards, Daniel. --[snip]-- insmod ohci module, camcorder is already turned on: ieee1394: registered ohci1394 driver, initializing now ohci1394: looking for Ohci1394 cards ohci1394_0: allocated interrupt 9 ohci1394_0: The 1st byte at offset 0x404 is: 0x31 ohci1394_0: remapped memory spaces reg 0xd086a000 ohci1394_0: soft reset finished ohci1394_0: max packet size = 2048 bytes ohci1394_0: 4 iso contexts available ohci1394_0: Receive DMA ctx=0 initialized ohci1394_0: Receive DMA ctx=1 initialized ohci1394_0: AT dma ctx=0 initialized ohci1394_0: AT dma ctx=1 initialized ohci1394_0: Receive DMA ctx=2 initialized ohci1394_0: request csr_rom address: C3258000 ohci1394_0: Cancel request received ohci1394_0: resetting bus on request and attempting to become root ieee1394: detected 1 ohci1394 adapter ohci1394_0: NodeID valid in 27. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf ohci1394_0: NodeID valid in 28. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf ohci1394_0: NodeID valid in 28. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04d20000, IntMask: 840300bf ohci1394_0: PhyControl: 800101FF ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00d00000, IntMask: 840300bf Turn off camcorder: ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80030600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf Turn on again: ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80070600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80070600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf ohci1394_0: NodeID valid in 16. cycle ohci1394_0: IntEvent: 04020000 ohci1394_0: IntEvent (raw): 04f20000, IntMask: 840300bf ohci1394_0: PhyControl: 80010600 ohci1394_0: IntEvent: 00000000 ohci1394_0: IntEvent (raw): 00f00000, IntMask: 840300bf kobras@polaris:~ > cat /proc/ohci1394 IEEE-1394 OHCI Driver status report: bus number: 0x3ff Node ID: 0x0 ### Host data ### node_count: 0 node_id : 00000000 irm_id : 0000FFFF busmgr_id : 0000FFFF initialized in_bus_reset attempt_root ---Iso Receive DMA--- Current buf: 0 offset: 0 ---Async Receive DMA--- Ar req current buf: 0 offset: 0 AR resp current buf: 0 offset: 0 ---Async Transmit DMA--- AT req prg: 0 sent: 0 free: 32 branchAddrPtr: 00000000 AT req queue: first: 00000000 last: 00000000 AR resp prg: 0 sent: 0 free: 32 branchAddrPtr: 00000000 AT resp queue: first: 00000000 last: 00000000 ### HC Register dump ### Version : 01010000 GUID_ROM : 00000000 ATRetries : 00000822 CSRReadData : 00000000 CSRCompData : 00000000 CSRControl : 80000000 ConfigROMhdr: 04040000 BusID : 31333934 BusOptions : f07da002 GUIDHi : 08004603 GUIDLo : 002aee04 ConfigROMmap: 03258000 PtdWrAddrLo : 00000000 PtdWrAddrHi : 00000000 VendorID : 00000000 HCControl : 004e0000 SelfIDBuffer: 02a11000 SelfIDCount : 00010000 IRMuChMaskHi: 00000000 IRMuChMaskLo: 00000000 IntEvent : 00f00000 IntMask : 840300bf IsoXmIntEvnt: 00000000 IsoXmIntMask: 00000000 IsoRcvIntEvt: 00000000 IsoRcvIntMsk: 00000001 FairnessCtrl: 00000000 LinkControl : 00300200 NodeID : 8800ffc0 PhyControl : 86000600 IsoCyclTimer: 5b3a5219 AsRqFilterHi: 80000000 AsRqFilterLo: 00000000 PhyReqFiltHi: 00000000 PhyReqFiltLo: 00000000 PhyUpperBnd : 00000000 AsRqTrCxtCtl: 00000000 AsRqTrCmdPtr: 00000000 AsRsTrCtxCtl: 00000000 AsRsTrCmdPtr: 00000000 AsRqRvCtxCtl: 00008400 AsRqRvCmdPtr: 02cefa81 AsRsRvCtxCtl: 00008400 AsRsRvCmdPtr: 02cefc81 IntEvent : 00f00000 IsoRCtxCtl00: d0008400 IsoRCmdPtr00: 02cefe81 IsoRCxtMch00: f0000000 IsoRCtxCtl01: 00000000 IsoRCmdPtr01: 00000000 IsoRCxtMch01: 00000000 IsoRCtxCtl02: 00000000 IsoRCmdPtr02: 00000000 IsoRCxtMch02: 00000000 IsoRCtxCtl03: 00000000 IsoRCmdPtr03: 00000000 IsoRCxtMch03: 00000000 ### Phy Register dump ### offset: 1 val: 0x2c -> RHB: 0IBR: 0 Gap_count: 44 offset: 2 val: 0xe3 -> SPD: 3 E : 1 Ports : 3 offset: 3 val: 0x41 -> [port 0] TPA: 1 TPB: 0 | parent disconnected offset: 4 val: 0x88 -> [port 1] TPA: 2 TPB: 0 | child disconnected offset: 5 val: 0x03 -> [port 2] TPA: 0 TPB: 0 | parent disconnected offset: 6 val: 0x00 -> ENV: backplane Reg_count: 0 |
From: <fir...@lo...> - 2000-05-12 18:06:57
|
On Fri, 12 May 2000, Sebastien Rougeaux wrote: > firewire-devel> We are trying to connect multiple computers using firewire for > firewire-devel> a high speed network, and are having a some problems with the > firewire-devel> driver. > > firewire-devel> When I load the driver on the first machine it can see all of > firewire-devel> the machines on the network. I used 'testlibraw' to check. > firewire-devel> Now when I load the drivers on the next machine 'testlibraw' > firewire-devel> reports that it is the only machine on the network, but > firewire-devel> 'testlibraw' on the first machine now shows comm between the > firewire-devel> two. Then when I try to load the drivers on the next machine, > firewire-devel> it has the same problem as the second machine, but now the > firewire-devel> second machine can see all of the nodes on the network. The > firewire-devel> keeps happening as I load the drivers on other machines. > > firewire-devel> So is there a way to get the last machine to see all the > firewire-devel> computers on the firewire network? > > For some reason, the ohci driver sometimes doesn't work properly on the > first 'insmod' after hardware reboot... have you tried to load it again > a couple of times and see if things are improving ? Well first off I am using the pcilynx driver, so I don't think that is the problem. I might have put down the wrong card in my previous email (could not remember the exact card). I did try your suggestion, but it did not work, testlibraw still does not see any of the nodes on the network. Thanks. Judd Tracy jt...@is... |
From: <fra...@ya...> - 2000-05-12 11:10:31
|
I have fix some Pbs with my virtal_VCR, by using the last dvgrab version 0.7 with a patch that can output files for playdv (last version). The movie is good (I can finally reconize the dog). But playdv crash at the end of the movie (segmentation fault), here is the error output : ** CRITICAL **: file bitstream.h: line 155 (bitstream_unget): assertion `(num_bits <= 32) && (num_bits >0) && (!(data & (~mask)))' failed. Since xdv0.1 does not correctly decode my isochrone flow, I will try to build a direct line movie player which will use dvgrab's --dv algorithms option and the libdv codecs. Currently, I have a ROM for IEEE 1394 boards. I have a small program that listen to FCP commands and try to respond like a VCR does. (Probably soon avaible) But I do not support yet all commands described in the AV/C Tape Recorder / Player Subunit Specification. In fact, I do not now exactly what is meaning of some commands. And what are the main commands to support. --- Franck Bonin --- Andreas Micklei a écrit : > Hi, > > On Thu, May 11, 2000 at 04:11:07PM +0200, Franck > Bonin wrote: > > So I have tryed to transform my PC-linux in an > > TapeRecorderPlayer and > > today I have succeded, by re-writing the > ohci_csr_rom > > located in the ohci1394.h file. > > That is great. Right now I use the Linux 1394 > subsystem mainly for controlling > a digital VCR. A virtual VCR on another Linux host > would provide the perfect > debugging tool for testing all those optional > features that real VCRs do not > implement yet. > > If you have some more specific questions, feel free > to ask. You can also send > me your source if you like. > > I would also like to see this thing run on an > unmodofied Linux kernel. We > would need an interface for changing the CSR ROM at > run time, oder maybe the > driver module should read the CSR rom from a file. > The filename could be > specified at module loading time as an optional > parameter. What do the driver > maintainers think of this idea? > > bye... > Andreas Micklei > ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Sebastien R. <Seb...@sy...> - 2000-05-12 09:21:55
|
>>>>> "Mark" == Mark Knecht <mk...@co...> writes: Mark> Sebastien, Without waiting for the ACK, or without waiting for the Mark> response packet? Mark The ohci driver just queues the outgoing packets that it receives from the subsystem into a fifo, and returns immediately after that, unless the fifo is full, in which case it is put to sleep and it should output a debug message (which I have never seen so far). No waiting for ack nor response packet (it is later signaled to the subsystem upon reception). -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-05-12 09:13:29
|
>>>>> "firewire-devel" == firewire-devel <fir...@se...> writes: firewire-devel> We are trying to connect multiple computers using firewire for firewire-devel> a high speed network, and are having a some problems with the firewire-devel> driver. firewire-devel> When I load the driver on the first machine it can see all of firewire-devel> the machines on the network. I used 'testlibraw' to check. firewire-devel> Now when I load the drivers on the next machine 'testlibraw' firewire-devel> reports that it is the only machine on the network, but firewire-devel> 'testlibraw' on the first machine now shows comm between the firewire-devel> two. Then when I try to load the drivers on the next machine, firewire-devel> it has the same problem as the second machine, but now the firewire-devel> second machine can see all of the nodes on the network. The firewire-devel> keeps happening as I load the drivers on other machines. firewire-devel> So is there a way to get the last machine to see all the firewire-devel> computers on the firewire network? For some reason, the ohci driver sometimes doesn't work properly on the first 'insmod' after hardware reboot... have you tried to load it again a couple of times and see if things are improving ? -- Sebastien Rougeaux RSISE, The Australian National University |
From: Arne S. <ar...@sc...> - 2000-05-12 06:06:16
|
libdv does both NTSC and PAL, if it is a recent version. There is a flag in the DV data that identifies NTSC or PAL format. Check the playdv.c from libdv for more info. My dvgrab program also distinguishes NTSC and PAL, but it is not so straightforward there (I should really fix this). Arne -----Original Message----- From: Brian Murray [SMTP:br...@pr...] Sent: Friday, May 12, 2000 3:50 AM To: Franck Bonin Cc: lin...@li... Subject: Re: Receiving Video from other Computer > I still have a problem concerning video decoding with > xdv. > I have attach a sample from the output gave by xdv > (does anyone see the dog ?). That looks exactly like an NTSC DV decoder fed with PAL DV material. The 'DVGate Still' windoze app that came with my Vaio did the same thing. Unfortunately it doesn't autodetect the video standard - it's hard-coded with a registry setting!!! I'd hope that xdv can do better than that (eventually). I heard that libdv is currently NTSC only - maybe that explains it? Otherwise nice work :) Brian. -- -- ----------------------------------- Brian Murray Proximity Pty Ltd http://www.proximity.com.au/~brian/ ----------------------------------- _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Sebastien R. <Seb...@sy...> - 2000-05-12 02:20:55
|
>>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= <iso-8859-1> writes: Franck> I may have found when exactly this bug append. Just try this : Franck> 1) insmod all the ieee 1394 modules (ieee1394, raw1394 & ohci1394) Franck> 2) delmod all the 3 modules. Franck> 3) generate a bus reset (by unplugging 1394 cables or insmoding ieee Franck> 1394 modules on another node) Franck> 4) re-insmod all the 3 modules... Franck> 5) CRASH! Franck> This bug is repetable as well with my ADS PYRO cards. It should be fixed now in the latest CVS version. The reason for this is that the board was not reset properly when unloading the driver. Thanks a lot for your bug report, -- Sebastien Rougeaux RSISE, The Australian National University |
From: <br...@pr...> - 2000-05-12 01:50:57
|
> I still have a problem concerning video decoding with > xdv. > I have attach a sample from the output gave by xdv > (does anyone see the dog ?). That looks exactly like an NTSC DV decoder fed with PAL DV material. The 'DVGate Still' windoze app that came with my Vaio did the same thing. Unfortunately it doesn't autodetect the video standard - it's hard-coded with a registry setting!!! I'd hope that xdv can do better than that (eventually). I heard that libdv is currently NTSC only - maybe that explains it? Otherwise nice work :) Brian. -- -- ----------------------------------- Brian Murray Proximity Pty Ltd http://www.proximity.com.au/~brian/ ----------------------------------- |
From: Andreas M. <ami@@ivistar.de> - 2000-05-11 14:37:07
|
Hi, On Thu, May 11, 2000 at 04:11:07PM +0200, Franck Bonin wrote: > So I have tryed to transform my PC-linux in an > TapeRecorderPlayer and > today I have succeded, by re-writing the ohci_csr_rom > located in the ohci1394.h file. That is great. Right now I use the Linux 1394 subsystem mainly for controlling a digital VCR. A virtual VCR on another Linux host would provide the perfect debugging tool for testing all those optional features that real VCRs do not implement yet. If you have some more specific questions, feel free to ask. You can also send me your source if you like. I would also like to see this thing run on an unmodofied Linux kernel. We would need an interface for changing the CSR ROM at run time, oder maybe the driver module should read the CSR rom from a file. The filename could be specified at module loading time as an optional parameter. What do the driver maintainers think of this idea? bye... Andreas Micklei |
From: <fra...@ya...> - 2000-05-11 14:12:13
|
Since few days I started to work on isochronous transfers. The main difficultie is that I don't (and I can't) have a camrecorder to generate an isochronous flow. Moreover, the IEEE 1394 linux subsystem is not able to generate one too. But I have a FireWire iMac and a PC-windoz, that are able to output isochronous packets IF they thought there is a TapeRecorderPlayer connected to the bus. So I have tryed to transform my PC-linux in an TapeRecorderPlayer and today I have succeded, by re-writing the ohci_csr_rom located in the ohci1394.h file. Now, the Imac think that my Pc-linux is a TapeRecorder and send it lots of fcp commands and isochronous packets that I can grab with dvgrab (but can not see with libdv) or I can directly see the movie with xdv. But since I don't now exactly how an IEEE 1394 TapeRecorder has to react, I just ask if someone is interrested by such work or has any experience with the AVC protocol for TapeRecorderPlayer. I still have a problem concerning video decoding with xdv. I have attach a sample from the output gave by xdv (does anyone see the dog ?). My goal is to build a TapeRecorder emulator on the top of the IEEE 1394 linux subsystem and one day (when isochronous output will work) a tape player. --- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: <fra...@ya...> - 2000-05-11 14:03:47
|
I may have found when exactly this bug append. Just try this : 1) insmod all the ieee 1394 modules (ieee1394, raw1394 & ohci1394) 2) delmod all the 3 modules. 3) generate a bus reset (by unplugging 1394 cables or insmoding ieee 1394 modules on another node) 4) re-insmod all the 3 modules... 5) CRASH! This bug is repetable as well with my ADS PYRO cards. --- Franck Bonin <Seb...@sy...> a écrit : > >>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= > <iso-8859-1> writes: > > Franck> Bug reporting with eth1394.c and ieee 1394 > subsystem My > Franck> Hardware/software > > Franck> 1) "Insmoding" 2 times the ohci module can > crash one or the other > Franck> PC... to avoid this problem I have to > restart my computer if I want > Franck> te re-insmod the ohci module. > > That's strange. Does it happen also if the pc is not > connected on the > bus ? Do you remove all the 1394 modules before > insmoding ? I don't > have a Pyro card here... anybody having the same > problem ? ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: <fra...@ya...> - 2000-05-11 14:03:41
|
I may have found when exactly this bug append. Just try this : 1) insmod all the ieee 1394 modules (ieee1394, raw1394 & ohci1394) 2) delmod all the 3 modules. 3) generate a bus reset (by unplugging 1394 cables or insmoding ieee 1394 modules on another node) 4) re-insmod all the 3 modules... 5) CRASH! This bug is repetable as well with my ADS PYRO cards. --- Franck Bonin <Seb...@sy...> a écrit : > >>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= > <iso-8859-1> writes: > > Franck> Bug reporting with eth1394.c and ieee 1394 > subsystem My > Franck> Hardware/software > > Franck> 1) "Insmoding" 2 times the ohci module can > crash one or the other > Franck> PC... to avoid this problem I have to > restart my computer if I want > Franck> te re-insmod the ohci module. > > That's strange. Does it happen also if the pc is not > connected on the > bus ? Do you remove all the 1394 modules before > insmoding ? I don't > have a Pyro card here... anybody having the same > problem ? ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Mark K. <mk...@co...> - 2000-05-11 13:30:18
|
I have some Pyro cards here, both LV22 and LV 23 based. I have not built the kernel in awhile, so I need to do that, but if someone can give me the EXACT instructions for insmod'ing I will be happy to try it out. (I do mean exact! I'm a hardware guy! Take pity!) Let me know. Mark -----Original Message----- From: Sebastien Rougeaux [mailto:Seb...@sy...] Sent: Wednesday, May 10, 2000 9:18 PM To: fra...@ya... Cc: lin...@li... Subject: Re: ethernet driver(bug report) >>>>> "Franck" == =?iso-8859-1?q?Franck=20Bonin?= <iso-8859-1> writes: Franck> Bug reporting with eth1394.c and ieee 1394 subsystem My Franck> Hardware/software Franck> 1) "Insmoding" 2 times the ohci module can crash one or the other Franck> PC... to avoid this problem I have to restart my computer if I want Franck> te re-insmod the ohci module. That's strange. Does it happen also if the pc is not connected on the bus ? Do you remove all the 1394 modules before insmoding ? I don't have a Pyro card here... anybody having the same problem ? Franck> 2) When I am using the ethernet driver with Pyro cards, I can Franck> succesfully ping others computers (flood ping works without any packet Franck> loss). Telnet is working fine, I can also start small X application Franck> like xcalc, xeyes or xclock. But, for exemple, if I was able to start Franck> bigger X applications with Adaptec HotConnect 8920 boards like Franck> Netscape or Xsoldier, It is no more possible with Pyro cards. So it is load related ? Franck> Few time after application start, one board stop receiving packets Franck> from the other board, as they still seem to be sent (by the other Franck> board), according to kernel messages output. Moreover, the failling Franck> card still can send packets. One thing I have noticed but haven't fixed yet is that the bottom halves in the irq handler are sometimes queued but not executed. You can try to call them directly (instead of queueing) and see if it helps. -- Sebastien Rougeaux RSISE, The Australian National University _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Mark K. <mk...@co...> - 2000-05-11 13:26:16
|
Sebastien, Without waiting for the ACK, or without waiting for the response packet? Mark -----Original Message----- From: Sebastien Rougeaux [mailto:Seb...@sy...] Sent: Wednesday, May 10, 2000 7:19 PM To: dai...@el... Cc: ana...@ut...; lin...@li... Subject: Re: Libraw1394 question >>>>> "Olivier" == Olivier Daigle <dai...@el...> writes: Olivier> --------------80790F6F4A9A7A46D27C5FE8 Content-Type: text/plain; Olivier> charset=us-ascii Content-Transfer-Encoding: 7bit Olivier> Hi Ashok, I managed to exchange raw data between 2 computers by using Olivier> an FCP-like method and libraw1394. Mainly, I copied FCP code and Olivier> extended it to allow data being transferred by chunks of 2k (instead Olivier> of 512 bytes with bare FCP code). This was pretty easy. Problem is: Olivier> there is a long delay between every data transfer and even with fast Olivier> machines (Pentium III 450MHz) and I can't manage to get data Olivier> transferred faster than 2.5 Mbytes/sec. By using Frank Bonin's Olivier> implementation of IP-over-1394 (which use async transactions), I can Olivier> ftp-transfer as fast as 15Mbytes/sec with slow machines (pentium Olivier> 200MMX) so I guess I should be able to do as fast as him... Olivier> I'm working on a way to speed-up transfer because I need at least Olivier> 12Mbytes/sec. I think the problem is that the code waits for an Olivier> acknowledge before sending another packet. If you have any other Olivier> suggestions, please help. The OHCI driver has been designed to send multiple packets without waiting for the ack (currently the max is set to 32)... However I think it never happens because of the internal mechanism of the subsystem/libraw. You probably should ask Andreas Bombe about that. -- Sebastien Rougeaux RSISE, The Australian National University _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Sebastien R. <Seb...@sy...> - 2000-05-11 11:41:18
|
>> Something wrong is happening during the bus reset phase, but there is not >> much I can do without the proper hardware to figure it out... I am >> starting to suspect that irqs are not detected properly... is the irq >> shared with other devices ? Daniel> Indeed it is shared, and it has worried me before. It looks like Sony Daniel> saved a few lines and routes every PCI device to IRQ 9. Both CardBus Daniel> controllers are actually active. The rest of the stuff shouldn't Daniel> generate any interrupts. Could you please add a debug message at the top of the irq handler, and verify that the irq handler is called when the driver is loaded. Something like this: /* read the interrupt event register */ event=reg_read(ohci, OHCI1394_IntEventSet); PRINT(KERN_INFO, ohci->id, "IntEvent: %08x",event); You should have something like this after `insmod ohci1394` ........ ohci1394_0: resetting bus on request and attempting to become root ieee1394: detected 1 ohci1394 adapter ohci1394_0: IntEvent: 00020010 ohci1394_0: IntEvent: 00020000 ohci1394_0: IntEvent: 00020000 ....... Daniel> Sebastien, below is a patch against the current ohci driver from CVS Daniel> which you might want to consider. It does Daniel> * process only those events in the IRQ handler that we haven't masked. Daniel> * shut up interrupts from the card before freeing the IRQ. * not go Daniel> through all ifs in the IRQ handler when there are no events to Daniel> process. Thanks, I will have a look at it. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Daniel K. <dan...@st...> - 2000-05-11 10:52:22
|
On Thu, 11 May 2000, Sebastien Rougeaux wrote: [No-go Sony CXD3222 w/ current OHCI driver] > Something wrong is happening during the bus reset phase, but there is > not much I can do without the proper hardware to figure it out... > I am starting to suspect that irqs are not detected properly... is the > irq shared with other devices ? Indeed it is shared, and it has worried me before. It looks like Sony saved a few lines and routes every PCI device to IRQ 9. Both CardBus controllers are actually active. The rest of the stuff shouldn't generate any interrupts. > Another stuff to look at is the > content of the phy registers (you might have to uncomment some > code and add a few debug lines in the driver source for that), and see > if there is something wrong (using the 1394 specs). I had only access to the OHCI specs so far but 1394 is on its way. I'll try to get my hands on the PHYs then. > Look also back > in the mailing list. Someone suggested to loop in the irq_handler until > the node id become valid... but I haven't done anything about that yet. Okay, I'll give it a try as well. Btw. is anyone else still seeing the no-nodes-on-bus problem with the CXD3222 chipset (that's Sony's OHCI-compliant chipset in latest Vaios)? Sebastien, below is a patch against the current ohci driver from CVS which you might want to consider. It does * process only those events in the IRQ handler that we haven't masked. * shut up interrupts from the card before freeing the IRQ. * not go through all ifs in the IRQ handler when there are no events to process. I think they are correct, however testing is a bit tough when the driver refuses to find any nodes on the bus. Well, my changes certainly didn't make things worse for me. ;) Regards, Daniel. Index: ohci1394.c =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v retrieving revision 1.26 diff -u -r1.26 ohci1394.c --- ohci1394.c 2000/04/25 09:46:32 1.26 +++ ohci1394.c 2000/05/11 09:31:44 @@ -1538,7 +1538,9 @@ do { /* read the interrupt event register */ - event=reg_read(ohci, OHCI1394_IntEventSet); + event=reg_read(ohci, OHCI1394_IntEventClear); + if (!event) + return; /* clear the interrupt event register */ reg_write(ohci, OHCI1394_IntEventClear, event); @@ -1700,11 +1702,9 @@ "sequence"); #endif } - timeout--; - } while (event && timeout); + } while (--timeout); - if (event) PRINT(KERN_ERR, ohci->id, - "irq_handler timeout event=0x%08x", event); + PRINT(KERN_ERR, ohci->id, "irq_handler timeout event=0x%08x", event); } /* Put the buffer back into the dma context */ @@ -2571,6 +2571,9 @@ free_dma_fbuf_ctx(&ohci->fbuf_context[i]); } #endif + + /* Shut up card */ + reg_write(ohci, OHCI1394_IntMaskClear, OHCI1394_masterIntEnable); /* Free self-id buffer */ if (ohci->self_id_buffer) -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: <And...@no...> - 2000-05-11 09:07:53
|
Hi, I am writing a program for handling changes on the bus after bus resets, i.e. detecting type of nodes (SBP2, AVC, ...) and building a topology tree. I use a DV camera (Sony DCRPC7E) and two SBP2 hard drives from VST and have come up with some strange behaviour when connecting/disconnecting these devices. The problems are consistant, i.e. I am able to repeate them, but it is difficult to say why they occur. This is my setup: * 1394 subsystem checked out from CVS yesterday * Kernel version 2.2.14 * Red Hat 6.1 * P166 PC with TI OHCI adapter card I use the following small test program: ---------------------------------------------------------------------------- ----- #include <stdio.h> #include <libraw1394/raw1394.h> int i = 0; void reset_handler( raw1394handle_t handle ) { printf("\nBus reset #%d detected!\n", i); i++; } int main( void ) { raw1394handle_t handle; handle = raw1394_get_handle(); raw1394_set_port(handle, 0); raw1394_set_bus_reset_handler( handle, (bus_reset_handler_t) reset_handler ); while(1) raw1394_loop_iterate(handle); return 0; } ---------------------------------------------------------------------------- -------- I also do a 'cat /proc/kmsg' to get the debugging information from the ohci and ieee modules. Please see my observations below. It is possible that the problems are hardware related, e.g. slow PC, inconsistant PHY and/or LINK chips etc but it would be interesting to see if someone else has encountered the same problems with other type of setups. In that case, it could be software related bugs. #1. A device is disconnected Sometimes reset_handler() is called but I do not get any debugging information from /proc/kmsg. #2. One SBP2 drive already connected to PC, DV camera is connected reset_handler() is called twice but /proc/kmsg only indicates one bus reset: <6>ohci1394_0: Bus reset <6>ohci1394_0: PhyControl: 000001FF <6>ohci1394_0: SelfID process finished (phyid 4, not root) <6>ohci1394_0: selfid packet 0x806c8094 rcvd <7>ieee1394: including selfid 0x94806c80 <6>ohci1394_0: selfid packet 0x812c849c rcvd <7>ieee1394: including selfid 0x9c842c81 <6>ohci1394_0: selfid packet 0x826c8094 rcvd <7>ieee1394: including selfid 0x94806c82 <6>ohci1394_0: selfid packet 0x832c84ec rcvd <7>ieee1394: including selfid 0xec842c83 <6>ohci1394_0: selfid packet 0x846c84b4 rcvd <7>ieee1394: including selfid 0xb4846c84 <6>ohci1394_0: This node self-id is 0x846c84b4 <6>ohci1394_0: selfid packet 0x856c08c2 rcvd <7>ieee1394: including selfid 0xc2086c85 <6>ohci1394_0: calling self-id complete <6>ohci1394_0: Got phy packet ctx=0 ... discarded #3. A device is connected to the PC, no other devices are connected No bus reset is generated at all. #4. DV camera already connected to PC, SBP2 drive is connected or disconnected reset_handler() is not called and /proc/kmsg says: <3>ohci1394_0: SelfID process finished but NodeID not valid: 0800FFC0 <6>ohci1394_0: PhyControl: 000001FF <6>ohci1394_0: Got phy packet ctx=0 ... discarded <6>ohci1394_0: Got phy packet ctx=0 ... discarded _____________________________________________________________________ Anders Weitman, M.Sc Phone : +46 (0)13 4611341 Development Engineer Fax : +46 (0)13 4611001 Nokia Home Communications Mobile : +46 (0)70 2141319 Diskettgatan 11 E-mail : and...@no... SE-583 35 Linkoping, Sweden Internet : www.nokia.com/multimedia/ |