linux1394-devel Mailing List for IEEE 1394 for Linux (Page 538)
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: hunter <hu...@ti...> - 2000-04-17 02:04:03
|
At 01:43 PM 4/16/00 +0900, Hiromasa Yoshimoto wrote: > I'm looking for CXD3222 data manual. The CXD3222 is a straight OHCI 1.0 link chip, so its Data Manual is the OHCI 1.0 specification. (There might be slight differences from the TI OHCI link chips, but those are within-spec implementation differences -- ie, nothing programmable.) Hunter |
From: Sebastien R. <Seb...@sy...> - 2000-04-16 23:21:49
|
>>>>> "Hiromasa" == Hiromasa Yoshimoto <yos...@li...> writes: Hiromasa> IntEvent.SelfIDComlete has never asserted. But NodeID register Hiromasa> has correct number. I'm looking for CXD3222 data manual. OK, so the problem remains... Hiromasa> I check header file, and found another bug. #define OHCI1394_postedWriteErr 0x00000100 #define OHCI1394_lockRespErr 0x00000200 Thanks. It will be corrected in the next cvs version. Hiromasa> I had been puzzled about rvmalloc() at bttv.c. I think static Hiromasa> void * rvmalloc(unsigned long size) should be static void * Hiromasa> rvmalloc(signed long size). Why ? It doesn't make sense to allocate a negative amount of memory... -- Sebastien Rougeaux RSISE, The Australian National University |
From: Wildcat <ca...@dc...> - 2000-04-16 16:58:31
|
I was wondering if there is any plans to include the ieee1394 drivers for a FireWire Western Digital Hard Drive...I have a 10 gigger that I would love to get running in Linux,seems that Kernal 2.3.99-pre3 finds my card when I compile but I dont know what to do to get it running...please let me know. Earl Brown ----- Original Message ----- From: <And...@no...> To: <and...@mu...>; <And...@no...> Cc: <lin...@li...> Sent: Sunday, April 16, 2000 7:48 AM Subject: RE: raw1394_stop_iso_rcv bug? > > 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. > > > If your iso handler doesn't expect that and segfaults the program > > appears to have crashed on stop_iso_rcv. > > Since my iso handler was called a couple of times extra, received packets > were written outside a memory buffer. > > Thanks! > > /Anders > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > |
From: <And...@no...> - 2000-04-16 14:55:38
|
> 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. > If your iso handler doesn't expect that and segfaults the program > appears to have crashed on stop_iso_rcv. Since my iso handler was called a couple of times extra, received packets were written outside a memory buffer. Thanks! /Anders |
From: Hiromasa Y. <yos...@li...> - 2000-04-16 04:50:54
|
Sebastien Rougeaux <Seb...@sy...> wrote: > I am chasing the bug that causes the node count to stay at zero on > some ohci chipset. I think I have found a possible culprit, but IntEvent.SelfIDComlete has never asserted. But NodeID register has correct number. I'm looking for CXD3222 data manual. I check header file, and found another bug. #define OHCI1394_postedWriteErr 0x00001000 #define OHCI1394_lockRespErr 0x00002000 =>#define OHCI1394_postedWriteErr 0x00000100 =>#define OHCI1394_lockRespErr 0x00000200 > Anyway I have updated the CVS with the fix, and also with > some development code for direct DMA to user space (not > ready yet, don't bother to use it). I had been puzzled about rvmalloc() at bttv.c. I think static void * rvmalloc(unsigned long size) should be static void * rvmalloc(signed long size). |
From: Andreas B. <and...@mu...> - 2000-04-15 19:13:45
|
On Sat, Apr 15, 2000 at 05:46:34PM +0200, Manfred Weihs wrote: > Andreas Bombe wrote: > > You can get both from CVS, apart from successful compilation I haven't > > tested it. > > But ieee1394 does not compile (CVS-version from Apr 15 th, 17:40 CEST). > make bzImage says: > ... > drivers/ieee1394/ieee1394.a(pcilynx.o): In function `mem_dmaread': > pcilynx.o(.text+0x10cf): undefined reference to `set_current_state' > make: *** [vmlinux] Error 1 set_current_state didn't exist in Linux 2.2. I added a compatibility macro (in CVS), it should work now. -- 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-15 15:54:20
|
Andreas Bombe wrote: > You can get both from CVS, apart from successful compilation I haven't > tested it. But ieee1394 does not compile (CVS-version from Apr 15 th, 17:40 CEST). make bzImage says: ... drivers/ieee1394/ieee1394.a(pcilynx.o): In function `mem_dmaread': pcilynx.o(.text+0x10cf): undefined reference to `set_current_state' make: *** [vmlinux] Error 1 Manfred Weihs |
From: Arne S. <ar...@sc...> - 2000-04-15 07:46:16
|
1. the iso write function. My motivation for writing the dvgrab program was that the Windows98 grab software available to me was too awkward to use. File size limits, no split into smaller files, no control about dropped frames and the like. Now, after dvgrab is useable, I discovered that the write-back-to-the-camcorder function of my Windows98 program suffers from the same deficits too. In particular: It will write only one file to the camcorder, it has a file size limit, the user is not informed about dropped frames, it will not write all types of DV-AVI files. So, once I have the iso write function (or whatever is needed to write data to a camcorder), I would like to make a program that will write several AVI files in one session, provides feedback about data over-/underrun and supports more than one flavour of AVI file. 2. a way of controlling the device driver's buffer size The 1394 subsystem currently uses a buffer size of 4 MByte, which is hardcoded in raw1394.c. I always have a problem with hardcoded limits, they are always either too big or too small. One size doesn't fit all. With my somewhat dated hardware system (AMD 333, slow IDE disks) I have to change this limit to 24 MByte to avoid any data loss. Smaller buffer sizes eventually result in dropped frames. Remember that I use dvgrab to copy whole tapes to disk, usually 10 GByte in one session. My suggestion would be a command line option at insmod time (buf=24M for example). Arne |
From: Andreas B. <and...@mu...> - 2000-04-15 03:10:34
|
On Fri, Apr 14, 2000 at 05:35:23PM +0300, And...@no... wrote: > Hi Andreas, > > I have downloaded the latest subsystem and libraw code from the CVS > repository. I think I may have discovered a bug when disabling iso > reception. If raw1394_stop_iso_rcv() isn't called immediately after > raw1394_loop_iterate() is called, I get a segmentation fault inside > raw1394_stop_iso_rcv(). I haven't had the time to check the code yet but my > theory is that there is some problem with unprocessed messages. 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. If your iso handler doesn't expect that and segfaults the program appears to have crashed on stop_iso_rcv. You could run your program in gdb or let it create a core file and examine it with gdb (the interesting gdb command there is "backtrace" which shows you were it has crashed and the call chain). > I made a small test by adding a delay between the loop_iterate and > stop_iso_rcv calls. Having usleep in the code always results in a > segmentation fault but if it's removed it works fine. > > > while(pkts_received < packets) > raw1394_loop_iterate(handle); > > usleep(50000); > > raw1394_stop_iso_rcv(handle, CHANNEL); I have tried equivalent code with up to 5 seconds delay without problems (and getting remaining iso packets to the handler during the stop call). -- 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-15 02:58:17
|
On Fri, Apr 14, 2000 at 01:36:46PM +0200, Manfred Weihs wrote: > > > On Fri, 14 Apr 2000, Andreas Bombe wrote: > > > Could you please apply the following patch to pcilynx.c directly > > (i.e. cd into drivers/ieee1394 directory and "patch pcilynx.c <patch") > > It will probably say that it moved the hunk because I have changed my > > pcilynx.c a bit but that's no problem. The patched file should log > > length mismatches with the register content, please send them to me. > > OK. I here is that part of my /var/log/messages, which is of interrest: > > Apr 14 13:21:10 localhost kernel: pcilynx0: sent reject > Apr 14 13:21:10 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a014c > Apr 14 13:21:12 localhost kernel: pcilynx0: sent reject > Apr 14 13:21:12 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02dc Now that I've been running with this, I got the same errors... It's apparantly caused by receive buffer overflows. Some data gets lost, so the DMA does and reports smaller packets than the iso header. > I should mention that this especially happens, if there is higher load on > my system, eg. if I start netscape and load a page. ... which might cause heavy activity on the PCI bus so that the FIFO on the Lynx can't be emptied in time and overflows. 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. This might cause transmits to fail due to underruns on the transmit FIFO. Try it and see if there are problems. It would be possible to do dynamic resizing based on overflow / underrun statistics... -- 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-15 00:45:07
|
On Fri, Apr 14, 2000 at 06:43:30PM +0200, Manfred Weihs wrote: > Well, I think there are many things, the linux world needs. Maybe it > would be nice to create a kind of wish list. Would be a good idea (together with information on who does/intends to work on specific items). > But I think, before such substantial additions are made (which of course > should come soon or later), it should have a higher priority to fix the > bugs in the existing fundamental operations. For example the lock > operation does not work, because we do not get the response value. > Therefore I cannot do a compare-swap-operation, because the return value > is essential for that kind of operation. And I need this :-( Oh, you mentioned that some time ago already. Sorry, I completely forgot that. I fixed that now, the necessary changes in libraw1394 were quite small, and the lock functions now take an additional quadlet_t* pointing to a location where the response is to be stored. I also fixed the kernel side raw1394 lock, where for remote transactions a pointer was not set (could get you a nasty oops). You can get both from CVS, apart from successful compilation I haven't tested it. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Bryan S. <ar...@ve...> - 2000-04-14 21:17:02
|
Stefan Lucke sent me this patch to try out, and while it didn't completely work it was /real/ close to fixing my problem. After applying this patch the video is just about perfect except it's rotated vertically a little. The sound is a lot better too, but it's still not right. Hopefully someone knows what's missing to fix the rest of my problems... :) I thought it looked kind of weird being 0x78787868 so I tried 0x78787878 and there really wasn't a difference between the two outputs. I also ran in to some compile problems (I guess I didn't recompile before like I thought), but I was able to fix one 'undefined function'(not sure if that's the error) by including stduni.h in avi.cc and dvgrab.cc I think. I could check again when I get home. There was also a function that I had to specifically specify a return type of int for it to compile. (Again I'll get that when I'm at home.) Bryan ---------- Forwarded message ---------- Date: Thu, 13 Apr 2000 22:04:32 +0200 From: Stefan Lucke <lu...@be...> To: ar...@ve... Subject: Re: dvgrab Bryan Stillwell wrote: > > Ok, I tried both even though it's supposed to be ntsc. Neither worked. > > > did you use the --pal or --ntsc parameter, depending of the type of your camera? > > Nope, neither Microsoft Media Player or ULead VideoStudio worked. They > > both in fact created the same screwed up picture. The movie plays, but > > the picture is screwed and audio is just a hiss. I've got a mixed pixel boxed image too. Perhaps the camera does not start transmitting iso data on frame boundary. So try to replace in avi_iso_handler (..) the line: if ((data[2] & 0xffff0000) != 0xffff0000) by if (((int) data [4]) == 0x78787868) I can not verify if this helps (since this is linux box only) and required hardware is a few miles away. Stefan Lucke |
From: Timothy M. S. <ts...@k-...> - 2000-04-14 21:08:53
|
Point well taken ... for everyone for whom Linux non-linear editing is the Holy Grail ... there are PUH-LENTY of things that need work - no reason to go pestering the hardware guys :) Since we can't do iso writes, on to DV decoding ... Tim > ----- Original Message ----- > From: "Manfred Weihs" <e95...@st...> > Cc: <lin...@li...> > Sent: Friday, April 14, 2000 9:43 AM > Subject: Re: we need the iso write function (was RE: dvgrab) > > > > Arne Schirmacher wrote: > > > Dear 1394 device driver programmers: please make a iso write function. > The > > > Linux world needs it ... :-) > > > > Well, I think there are many things, the linux world needs. Maybe it > > would be nice to create a kind of wish list. > > But I think, before such substantial additions are made (which of course > > should come soon or later), it should have a higher priority to fix the > > bugs in the existing fundamental operations. For example the lock > > operation does not work, because we do not get the response value. > > Therefore I cannot do a compare-swap-operation, because the return value > > is essential for that kind of operation. And I need this :-( > > > > Manfred Weihs > > > > _______________________________________________ > > mailing list lin...@li... > > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > > > |
From: Alastair M. <ala...@ww...> - 2000-04-14 20:46:28
|
A couple of days ago Bryan Stillwell mentioned that he was getting scrambled images (eg http://www.verinet.com/~arcane/screwedup.jpg ). Compare that to the slide of how a DV packet is assembled by taking chunks (8x32) from different areas of the image: http://desktopvideo.miningco.com/compute/desktopvideo/library/graphics/dvpres/bgSlide23.GIF (sorry for the ridiculously long URL) The little black rectangles mixed in with the purple and orange ones show where the pixel data for the first video segment comes from. The scrambled image above exhibits a similar arrangement of pixel blocks. I think (from a quick glance over the code) that dvgrab just puts the DV data into the AVI file in the order in which it was received, and that some AVI-playing software is smart enough to reassemble the chunks into correct order for display (if it recognizes the frames as DV). Part of making a more general DV codec will of course be shifting this stuff around into pixel-orders more recognizable by other graphic pgms, and vice versa. If I have enough time this weekend I'll get dvgrab running on my system and start working on code to do that. -- Alastair |
From: Manfred W. <e95...@st...> - 2000-04-14 16:51:37
|
Arne Schirmacher wrote: > Dear 1394 device driver programmers: please make a iso write function. The > Linux world needs it ... :-) Well, I think there are many things, the linux world needs. Maybe it would be nice to create a kind of wish list. But I think, before such substantial additions are made (which of course should come soon or later), it should have a higher priority to fix the bugs in the existing fundamental operations. For example the lock operation does not work, because we do not get the response value. Therefore I cannot do a compare-swap-operation, because the return value is essential for that kind of operation. And I need this :-( Manfred Weihs |
From: Alastair M. <ala...@ww...> - 2000-04-14 16:02:02
|
Hi, If anyone's keeping track of these things, the D-Link DFW-500 FireWire Adapter Card works OK. It's an OHCI card, so it ought to, but I had to wrestle with my software configuration a bit (my fault). This card is fairly recent and is showing up in places like Best Buy (a consumer electronics/appliances chain) for under $80. The software problems were really just a matter of old software. I'm running SuSE 6.4 which is a 2.2.14 kernel and comes with the ieee1394 patches applied and modules built -- the catch is that they're several months old and don't work well with the more recent versions of dvgrab and testlibraw that I downloaded. Yesterday I pulled all the latest stuff out of CVS and rebuilt the modules (and now I see there's even a later version of OHCI) and testlibraw now correctly reports the node count. I also tried gscanbus and could successfully see my camcorder (Sony TRV103) attach and disconnect, and I could control it via the gscanbus GUI. (I did have a problem with dvgrab -- the downloaded binary complained about something being out of synch and needing relinking, and I got compile errors when I tried to recompile, but I need to check my include paths etc.) Thanks guys, keep up the good work. And now that I have known-working platform I can start to contribute something back (mind, I'm more of an applications guy than a driver hacker.) -- Alastair |
From: <And...@no...> - 2000-04-14 15:16:26
|
Hi Andreas, I have downloaded the latest subsystem and libraw code from the CVS repository. I think I may have discovered a bug when disabling iso reception. If raw1394_stop_iso_rcv() isn't called immediately after raw1394_loop_iterate() is called, I get a segmentation fault inside raw1394_stop_iso_rcv(). I haven't had the time to check the code yet but my theory is that there is some problem with unprocessed messages. I made a small test by adding a delay between the loop_iterate and stop_iso_rcv calls. Having usleep in the code always results in a segmentation fault but if it's removed it works fine. while(pkts_received < packets) raw1394_loop_iterate(handle); usleep(50000); raw1394_stop_iso_rcv(handle, CHANNEL); Best regards, Anders Weitman _____________________________________________________________________ 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/ |
From: Duncan B. <dun...@ox...> - 2000-04-14 12:32:30
|
> Who is working on SBP-2 implementaion on this > and are there any specs available ? A guy called Mark Hatle is working on the SBP-2 drivers using the Oxford Semiconductor IDE bridge chip. A draft version of the SBP-2 spec is available for download from http://www.t11.org/t10/drafts.htm#1394 The final version is available from www.ncits.org for US$20. Regards, Duncan Beadnell Project Engineer _______________________________________________________________________ Oxford Semiconductor, 69 Milton Park, Abingdon, Oxon., OX14 4RX, UK mailto:dun...@ox... Tel: +44 (0)1235 824907 http://www.oxsemi.com Fax: +44 (0)1235 821141 |
From: Manfred W. <e95...@st...> - 2000-04-14 11:44:06
|
On Fri, 14 Apr 2000, Andreas Bombe wrote: > Could you please apply the following patch to pcilynx.c directly > (i.e. cd into drivers/ieee1394 directory and "patch pcilynx.c <patch") > It will probably say that it moved the hunk because I have changed my > pcilynx.c a bit but that's no problem. The patched file should log > length mismatches with the register content, please send them to me. OK. I here is that part of my /var/log/messages, which is of interrest: Apr 14 13:21:10 localhost kernel: pcilynx0: sent reject Apr 14 13:21:10 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a014c Apr 14 13:21:12 localhost kernel: pcilynx0: sent reject Apr 14 13:21:12 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02dc Apr 14 13:21:12 localhost kernel: pcilynx0: sent reject Apr 14 13:21:12 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02fc Apr 14 13:23:03 localhost kernel: pcilynx0: sent reject Apr 14 13:23:03 localhost kernel: pcilynx0: sent reject Apr 14 13:23:03 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c Apr 14 13:23:03 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c Apr 14 13:25:09 localhost kernel: pcilynx0: sent reject Apr 14 13:25:09 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a014c Apr 14 13:25:27 localhost kernel: pcilynx0: sent reject Apr 14 13:25:27 localhost kernel: pcilynx0: sent reject Apr 14 13:25:27 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c Apr 14 13:25:28 localhost kernel: pcilynx0: sent reject Apr 14 13:25:28 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c Apr 14 13:25:28 localhost kernel: pcilynx0: sent reject Apr 14 13:25:28 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c Apr 14 13:25:33 localhost kernel: pcilynx0: sent reject Apr 14 13:25:33 localhost kernel: pcilynx0: iso length mismatch 0x030841a0/0x484a02bc Apr 14 13:26:34 localhost kernel: pcilynx0: sent reject Apr 14 13:26:34 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c Apr 14 13:29:34 localhost kernel: pcilynx0: sent reject Apr 14 13:29:34 localhost kernel: pcilynx0: sent reject Apr 14 13:29:34 localhost kernel: pcilynx0: iso length mismatch 0x024841a0/0x484a014c I should mention that this especially happens, if there is higher load on my system, eg. if I start netscape and load a page. Manfred Weihs |
From: Sebastien R. <Seb...@sy...> - 2000-04-14 07:23:29
|
Hi, I am chasing the bug that causes the node count to stay at zero on some ohci chipset. I think I have found a possible culprit, but I can't be sure since I don't have this problem with my card and I don't have the troublesome hardware here. The problem I have found is that the linkEnable is set before the interrupt mask is set. Triggering a bus reset before enabling the interrupt might well be the reason the self-id packets are lost. Anyway I have updated the CVS with the fix, and also with some development code for direct DMA to user space (not ready yet, don't bother to use it). Please try the updated driver, and see if it fixes the problem (or introduce some new ones). -- Sebastien Rougeaux RSISE, The Australian National University |
From: Andreas B. <and...@mu...> - 2000-04-14 02:01:56
|
On Thu, Apr 13, 2000 at 06:07:30PM -0700, Richard_Harding@Playstation.sony.com wrote: > I'm wondering how to do point-to-point, asynchronous communciation (just send > and receive blocks of quadlets) between two computers using lib1394raw? > Eventually, I imagine there existing an IP-over-IEEE1394 implementation, but in > the meantime how does one go about doing more basic communications between nodes > on the bus? > > I guess my question really boils down to: How does one map the CSR address > space into user/application data space? Not possible currently, probably not in the future. Requests are processed immediately in the subsystem in interrupt context, there is no chance of asking a user space process what to do in there without serious rewrites. So either give at least one side a kernel driver handling the address space or use the FCP_COMMAND/FCP_RESPONSE registers which are passed on to user space (that's easy for FCP type commands since the response is a completely separate transaction to the command). -- 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-14 01:40:55
|
On Thu, Apr 13, 2000 at 01:05:57PM +0300, And...@no... wrote: > Hi Andreas and Sebastien, > > I was wondering if you could give me some estimate of when to expect DMA > transfer or mapping of iso data to user space? I would really want to have > this for our DV decoder. Second on my ToDo list (after getting that subsystem initiated transactions and GUID collecting to work). The first step to zero copy would be to make the hardware drivers use subsystem provided buffers for iso receiving instead of their own (and write code to manage locking and automatic freeing of those buffers in the subsystem). After that exists it would be a small step to actually mapping those buffers to user space. I don't think implementing mapping in the current raw1394 would a good idea since it would have to be rewritten then. -- 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-14 01:40:46
|
On Thu, Apr 13, 2000 at 06:58:48PM +0200, Arne Schirmacher wrote: > That would be in fact the next step, but currently there is no iso write > function available in the device driver. > > Which is really annoying because the dumb ULead VideoStudio program can only > write one single file back to the camcorder, which is limited to 4 GByte in > size, which is no more than 15 minutes. > > Dear 1394 device driver programmers: please make a iso write function. The > Linux world needs it ... :-) A clean implementation of that needs the subsystem to do transactions without being asked to by a user process. That is also needed for collecting GUIDs from connected nodes, so it's high on my todo list. And I hopefully will finally get this done in the very near future. -- 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-14 01:40:24
|
On Tue, Apr 11, 2000 at 03:35:11PM +0200, Manfred Weihs wrote: > But sometimes I received packets where the length argument sayed that the > packet length was 332 wherea the iso header (ie. data[0] >> 16) sayed 584. > Since I know the size of my iso packets, I can tell you that (of course) > the iso header is right and the length argument reports an incorrect > length. The initial length comes from the hardware driver and is passed through to raw1394 (which uses it to allocate a buffer) and then on to user space and to the handler by libraw1394. It is not looked up from the actual header anywhere. > So two questions emerge: > 1) Why does the handler report an incorrect packet length? Good question. Apparantly because the PCILynx reports lower packet lengths in the DMA stat register. But why it does that I don't know. I just looked over my driver to see whether there are any bugs in that code, but basically the transfer count is just taken from the reg and passed on. > 2) Is the buffer (*data) filled correctly or are only the first 332 > bytes valid and the rest (256 Bytes) lost? raw1394 only uses the length from hardware driver to decide how much to save, so the rest is lost. Could you please apply the following patch to pcilynx.c directly (i.e. cd into drivers/ieee1394 directory and "patch pcilynx.c <patch") It will probably say that it moved the hunk because I have changed my pcilynx.c a bit but that's no problem. The patched file should log length mismatches with the register content, please send them to me. --- pcilynx.c~ Thu Apr 13 03:37:57 2000 +++ pcilynx.c Fri Apr 14 03:14:33 2000 @@ -1175,6 +1175,12 @@ data = lynx->iso_rcv.page[idx / ISORCV_PER_PAGE] + (idx % ISORCV_PER_PAGE) * MAX_ISORCV_SIZE; + if ((*data >> 16) + 4 != (lynx->iso_rcv.stat[idx] & 0x1fff)) { + PRINT(KERN_ERR, lynx->id, + "iso length mismatch 0x%08x/0x%08x", *data, + lynx->iso_rcv.stat[idx]); + } + if (lynx->iso_rcv.stat[idx] & (DMA_CHAN_STAT_PCIERR | DMA_CHAN_STAT_PKTERR)) { PRINT(KERN_INFO, lynx->id, -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Richard_Harding@Playstation.sony.com - 2000-04-14 01:13:25
|
I'm wondering how to do point-to-point, asynchronous communciation (just send and receive blocks of quadlets) between two computers using lib1394raw? Eventually, I imagine there existing an IP-over-IEEE1394 implementation, but in the meantime how does one go about doing more basic communications between nodes on the bus? I guess my question really boils down to: How does one map the CSR address space into user/application data space? FYI: In case anyone is interested in adaptor compatiblity. I've got a SIIG 3-Port PCI (OHCI) adaptor working under Linux 2.3.99-pre3. Thanks in advance. |