linux1394-devel

Understanding the form of IEEE1394 subsystem

[Mark K. <mk...@co...>]

Hi,
   One of my good software guys and I are starting to dig into the driver
portion of the 1394 subsystem. We have our own set of 1394 drivers for a
different operating system that do not exhibit the Self-ID problems we have
here, and we'd like to try and get that fixed. 
 
   To speed things up I'm wondering if anyone has put together any
description of how all the basic pieces of the low level portions fit
together? If anyone has looked at this and documented it, we'd certainly be
more effective if you could share it. If not, here's our 15 minute cut at
the problem. Anyone who knows differently please comment.
 
   Results of this process will certainly be shared.
 
Thanks,
Mark
 
SO FAR...
 
   There are 10 C files, 9 with code and one with EXPORT symbols. Of the 9
files, we have tentatively divided them (by guessing) into 4 groups:
 
1) Low level, talk to the hardware:
 
ohci1394.c
 
2) Higher level interfacing upward, called by apps:
 
highlevel.c
raw.c (here or down 1 level?)
 
3) In between:
 
ieee1394_core.c
ieee1394_transactions.c
events.c
 
4) Ancillary - Used when required, but not on every transaction:
 
csr.c
guid.c
hosts.c
 
 

Lucent OHCI controller (2nd try)

[Jurgen K. <GTM...@in...>]

Hi,

I have bought two new PCI IEEE 1394 OHCI 1.0 complaint controllers which
are not recognized by the current drivers (both CVS and kernel). The
card is a Dynalink 1394P which uses a controller from Lucent
Microelectronics. The vendor ID is also not recognized by the kernel so
I lookup up the vendor ID at the PCI Special Interest Group but it's not
there (yet?). So here are the numbers:

Vendor ID: 0x11c1    Lucent Microelectronics
Device ID: 0x5811    FW323

For more info:

http://www.lucent.com/micro/1394/document.html

FW323 Integrated OCHI Link and PHY

 http://www.lucent.com/micro/1394/docs/PN99156-02.pdf


After modifing both ohci1394.h and ohci1394.c the cards worked so there
is no problem there.
Could you insert this device in your code?

Thanks,

Jurgen

List Activity

[Sven Nguyen-N. <sv...@st...>]

Is this list still active? I haven't received any mailings in over a month.
Sorry about the spam...

Re: OHCI and reply packets

[Olivier D. <dai...@el...>]

James,
  Thanks for the ack hack. But I realized that this patch was already int=
o
ohci1394.c. Yesterday I made a mistake when adding a debug info to see
whether or not reply packets were sent: it always told me that a reply
packet was sent, even if the incoming packet was seen by
handle_incoming_packet() as a broadcast. So, the code was already working=

fine...

  You are right when you say that handle_incoming_packet() should have a
parameter telling what kind of ack has been sent. It would be a lot
cleaner.

  Thanks again for your help.

     Olivier

James Goodwin wrote:

> Hi Oliver,
>
> You are right. This middle address range is also useful for protocols
> such as SBP-2 to save a split transaction on final transfer status (use=
d
> for performance reasons). The ack packet sent by the OHCI hardware for
> the first subaction is an ack_complete (for the middle address range).
>
> The function hpsb_packet_received in the ieee1394 module should have an=

> additional "ack sent" parameter (in this case, it would be
> ack_complete), that way the ieee1394 module can determine whether it
> needs to send a response or not.
>
> Quick hack for the ohci driver is to add the following in dma_rcv_bh
> (two places):
>
> if (tcode !=3D 0xE) {
>         DBGMSG(ohci->id, "Packet received from node"
>                 " %d ack=3D0x%02X spd=3D%d tcode=3D0x%X"
>                 " length=3D%d data=3D0x%08x ctx=3D%d",
>                 (buf_ptr[1]>>16)&0x3f,
>                 (buf_ptr[length/4-1]>>16)&0x1f,
>                 (buf_ptr[length/4-1]>>21)&0x3,
>                 tcode, length, buf_ptr[3], d->ctx);
>
>         //
>         // Begin of added hack code.
>         // If we receive an ack_complete (middle address space), we
> should
>         // not send a response. Fake out ieee1394 module by turning the=

> packet
>         // into a broadcast packet... we should really modify the core
> stack
>         // to accept an "ack sent" argument in hpsb_packet_received and=

> let
>         // it figure out whether to send a response packet.
>         //
>         if (((buf_ptr[length/4-1]>>16)&0x1f) =3D=3D 0x11) {
>                 buf_ptr[0] |=3D (ALL_NODES<<16);
>         }
>         //
>         // End of added hack code
>         //
>
>         hpsb_packet_received(ohci->host, buf_ptr, length);
> }
>
> Cheers,
> --James
>
> >Date: Wed, 07 Jun 2000 08:02:29 -0400
> >From: Olivier Daigle <dai...@el...>
> >Organization: Harfang
> >To: Linux1394-devel <lin...@li...>
> >Subject: OHCI and reply packets
> >
> >Hi,
> >  I noticed in the OHCI specification (release 1.1, January 6, 2000)
> >that when writing a packet to the Middle Address Space (region between=

> >physicalUpperBound (usually 48h'0001_0000_0000) and
> 48'hfffe_ffff_ffff),
> >packets should be acknowledged immediately with an ack_complete instea=
d
> >of an ack_pending (making the transaction unified). Problem is: when
> >sending a packet to 48h'fff8_0000_0000 (should be in the Middle Addres=
s
> >Space), the subsystem still send a response packet. Since I don't have=

> a
> >bus analyzer, I can't say if the ack packet sent for the first
> subaction
> >is ack_complete or ack_pending.
> >
> >  I guess this should not happen. The Middle Address Space seems to be=

> >reserved for unified transactions, which are really useful. Having thi=
s
> >memory region responding correctly to write transactions would make it=

> >easier to support unified transactions as we would not have to patch
> >handle_incoming_packet() (like Franck Bonin did for it's
> ether-over-1394
> >module) every time we want to use them. I don't know if it's the ohci
> or
> >ieee1394 module that is responsible of handling this. Probably both of=

> >them... And also, this would encourage the use of addresses other than=

> >CSR addresses (48'hffff_f000_000 to 48'hffff_ffff_ffff) for
> >communications, which are said to be reserved by the ISO/IEC 13123:199=
4
> >standard.
> >
> >  Maybe there's something I missed and I'm wrong. In this case, I>
> >apologize for my ignorance.
> >
> >  Regards,
> >
> >    Olivier
> >
> >--
> >Olivier Daigle
> >Projet Harfang
> >=3DC9cole de Technologie Sup=3DE9rieure
> >Universit=3DE9 du Qu=3DE9bec
> >(514) 396-8800 ext.7699

--
Olivier Daigle
Projet Harfang
=C9cole de Technologie Sup=E9rieure
Universit=E9 du Qu=E9bec
(514) 396-8800 ext.7699

the isoRX interrupt when stopping a running IR context.

[<gra...@dg...>]

Hi, all.

I have installed the ohci linux driver from CVS.
When those modules are unloaded from kernel, 
the isochRX interrupt occurred with "reg_write(ohci, d->ctrlClear/* OHCI1394_IrRcvContextMatch*/, 0x8000);" in free_dma_rcv_ctx().
Those log messages are as follow.

Jun  8 22:32:34 baekma kernel: ohci1394_0 : Cancel request received 
Jun  8 22:32:34 baekma kernel: ohci1394_0 : Freeing dma_rcv_ctx 0 
Jun  8 22:32:34 baekma kernel: ohci1394_0 : Freeing dma_rcv_ctx 1 
Jun  8 22:32:34 baekma kernel: ohci1394_0 : Freeing dma_trm_ctx 0 
Jun  8 22:32:34 baekma kernel: ohci1394_0 : Freeing dma_trm_ctx 1 
>
Jun  8 22:32:34 baekma kernel: ohci1394_0 : Freeing dma_rcv_ctx 2 
Jun  8 22:32:34 baekma kernel: ohci1394_0 : IntEvent: 00000080 
Jun  8 22:32:34 baekma kernel: ohci1394_0 : Got isochRx interrupt status=0x00000000 isoRecvIntEvent=00000001 
>
Jun  8 22:32:34 baekma kernel: ohci1394_0 : IntEvent: 00000000 
Jun  8 22:32:34 baekma kernel: ohci1394_0 : Freeing it_dma_ctx  
Jun  8 22:32:34 baekma kernel: ohci1394_0: soft reset finished 
Jun  8 22:32:34 baekma kernel: ohci1394: removed ohci1394 module 
Jun  8 22:32:34 baekma kernel:  

Is that all right?

My 1394 host adaptor is a miro Studio DV with TSB12LV23
link layer chip and   TSB41LV03 chip physical layer.
Are anyone who sucess receiving iso streams with this adaptor and the linux driver ? 

RE: OHCI and reply packets

[James G. <jamesg@Filanet.com>]

Hi Oliver,

You are right. This middle address range is also useful for protocols
such as SBP-2 to save a split transaction on final transfer status (used
for performance reasons). The ack packet sent by the OHCI hardware for
the first subaction is an ack_complete (for the middle address range).

The function hpsb_packet_received in the ieee1394 module should have an
additional "ack sent" parameter (in this case, it would be
ack_complete), that way the ieee1394 module can determine whether it
needs to send a response or not.

Quick hack for the ohci driver is to add the following in dma_rcv_bh
(two places):

if (tcode != 0xE) {
	DBGMSG(ohci->id, "Packet received from node"
		" %d ack=0x%02X spd=%d tcode=0x%X"
		" length=%d data=0x%08x ctx=%d",
		(buf_ptr[1]>>16)&0x3f,
		(buf_ptr[length/4-1]>>16)&0x1f,
		(buf_ptr[length/4-1]>>21)&0x3,
		tcode, length, buf_ptr[3], d->ctx);

	//
	// Begin of added hack code.
	// If we receive an ack_complete (middle address space), we
should 
	// not send a response. Fake out ieee1394 module by turning the
packet 
	// into a broadcast packet... we should really modify the core
stack
	// to accept an "ack sent" argument in hpsb_packet_received and
let 
	// it figure out whether to send a response packet.
	//
	if (((buf_ptr[length/4-1]>>16)&0x1f) == 0x11) {
		buf_ptr[0] |= (ALL_NODES<<16);
	}
	//
	// End of added hack code
	//

	hpsb_packet_received(ohci->host, buf_ptr, length);
}

Cheers,
--James 

>Date: Wed, 07 Jun 2000 08:02:29 -0400
>From: Olivier Daigle <dai...@el...>
>Organization: Harfang
>To: Linux1394-devel <lin...@li...>
>Subject: OHCI and reply packets
>
>Hi,
>  I noticed in the OHCI specification (release 1.1, January 6, 2000)
>that when writing a packet to the Middle Address Space (region between
>physicalUpperBound (usually 48h'0001_0000_0000) and
48'hfffe_ffff_ffff),
>packets should be acknowledged immediately with an ack_complete instead
>of an ack_pending (making the transaction unified). Problem is: when
>sending a packet to 48h'fff8_0000_0000 (should be in the Middle Address
>Space), the subsystem still send a response packet. Since I don't have
a
>bus analyzer, I can't say if the ack packet sent for the first
subaction
>is ack_complete or ack_pending.
>
>  I guess this should not happen. The Middle Address Space seems to be
>reserved for unified transactions, which are really useful. Having this
>memory region responding correctly to write transactions would make it
>easier to support unified transactions as we would not have to patch
>handle_incoming_packet() (like Franck Bonin did for it's
ether-over-1394
>module) every time we want to use them. I don't know if it's the ohci
or
>ieee1394 module that is responsible of handling this. Probably both of
>them... And also, this would encourage the use of addresses other than
>CSR addresses (48'hffff_f000_000 to 48'hffff_ffff_ffff) for
>communications, which are said to be reserved by the ISO/IEC 13123:1994
>standard.
>
>  Maybe there's something I missed and I'm wrong. In this case, I>
>apologize for my ignorance.
>
>  Regards,
>
>    Olivier
>
>--
>Olivier Daigle
>Projet Harfang
>=C9cole de Technologie Sup=E9rieure
>Universit=E9 du Qu=E9bec
>(514) 396-8800 ext.7699

Re: Puzzling over stream

[Matt P. <ma...@ls...>]

Maybe this is a stupid question, but to quote Tina Turner, "What's hardware got
to do with it?"

The hardware should be spewing some isoc channel into a very big buffer,
allowing (what I'm presuming is) an applications program to parse the CIPs and
figure out where the start of frame is from the DV data (we are talking DV,
right?).  One way to implement this that comes to mind is a circular buffer.
The DMA descriptor program is the only thing that might need to be reset
periodically.

The reception of 1394 isoc data should not slow down your process, and parsing
a stream of DV to find the start of frame is pretty easy.

Regards,

Matt

Mark Knecht wrote:

> Daniel,
>    Assuming that I'm not too far off base above, then the question arises
> "How long, in real time, does it take for the reception of Iso packets to be
> reenabled so that acquisition of the next frame can begin?" I may be wrong,
> but from your and Franck's e-mails, it seems to me that you might be
> assuming that this is essentially instantaneous. I am thinking that it
> isn't.
>

--
/***********************
Matt Pujol
Product Marketing Manager
1394 and USB CoreWare Technologies

LSI Logic
2001 Danfield Court
Fort Collins, Co 80525
970-206-5816
mat...@ls...
***********************/

Re: [libdv-dev] RE: Streaming DV

[James B. <ja...@ex...>]

Mark Knecht wrote:
> 
> James,
>    Would it be possible to share more of the technical details of your
> accomplishments? One of my machines has XFree86 4.0 installed with 2D and 3D
> accelerations for a GeForce card. Unfortunately, when I recompiled the
> kernel for 1394 support, the GeForce driver complained about not being
> installed correctly and RPM didn't want to reinstall. I haven't gotten back
> to trying to fix that one yet.
> 
>    Is the code you did something that is specific to the graphics cards you
> are using, or could it be extended in some way to a general PC graphics
> card? (Assuming some baseline capabilities...
> 
>    My experience here says that showing folks 30FPS live video gets them
> excited about putting resources in to some projects

OK, I just did the initial import of "dviola", which - someday -  will
be a native DV nonlinear editing app.  The part you'll probably want to
see is "dvplay", a simple DV player.

There's a README in the source tree.  libdv is required.  Because dviola
and dvplay only accept input from files, 1394 support is not required.

http://sourceforge.net/project/?group_id=6661

Caveats: Only 16-bit visuals are supported; the window is half size
(320x240); NTSC DV only; 30fps on PII-450 (probably); only tested on
Voodoo3 and Matrox Millenium xservers; no audio.

I'd appreciate any reports of success/failure/performance... thanks...

-- 
James Bowman
ja...@ex...

RE: New Ether 1394 version

[Mark K. <mk...@co...>]

Franck,
   Have you done something to the underlying subsystem to improve the way
device insertion is handled? There is still the problem with disconnected
PCs receiving Self-ID packets. (The notes in the beginning of the OHCI1394.C
file and many e-mails...)

Thanks,
Mark

-----Original Message-----
From: Franck Bonin [mailto:fra...@ya...]
Sent: Wednesday, June 07, 2000 4:25 AM
To: lin...@li...
Subject: New Ether 1394 version


The ether1394 driver should now support bus reset and
node insertion.
I have tested this with my little network of two PC,
but if someone
could see if it works, even on a larger network, I'd
like to ear
about it.

Ether 1394 driver :
http://www.chez.com/kayle/IEEE_1394/ether_1394_0.1.2.tgz
Or
http://www.chez.com/kayle/ieee_1394.htm

-------
Franck Bonin

___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

RE: Puzzling over stream

[Mark K. <mk...@co...>]

Daniel,
   Point taken about the patch. However, it sounds like if I had installed
it I wouldn't have had any information to look at!! ;-)

   My question about the way things are working is more hardware than
software oriented. Let's assume that because of the way you structured your
program you wait for a complete frame to arrive, then you disable the
reception, process the frame, and then reenable reception and wait for the
next frame. OK so far?

   Assuming that I'm not too far off base above, then the question arises
"How long, in real time, does it take for the reception of Iso packets to be
reenabled so that acquisition of the next frame can begin?" I may be wrong,
but from your and Franck's e-mails, it seems to me that you might be
assuming that this is essentially instantaneous. I am thinking that it
isn't.

   When you reenable, you may not be at the beginning of a frame, so you may
have to wait up to 1/30 (1/25) of a second to get back to the start of a
frame. There might be other things going on also with how access to a
channel is governed by the subsystem, such as waiting for some interrupt to
happen. Anything like this and you'd suffer the latencies involved there.

   If reenabling was instantaneous, then it would seems to me when running
your stream program I would always be at 100% utilization. I would either be
receiving data or processing data, but I would always be doing something.
(Possibly receiving data does not utilize the machine 100%. Hardware DMA
wouldn't show up in TOP I think...) In Franck's program, because he has a
tight loop, he says he is at 100%. In yours, there is something else going
on which is getting in the way of doing the work. If there wasn't, then why
do my 400MHz machine and my 750MHz machine produce the same frame rates?

Mark

-----Original Message-----
From: Daniel Kobras [mailto:dan...@st...]
Sent: Wednesday, June 07, 2000 7:16 AM
To: Mark Knecht
Cc: Franck Bonin; lin...@li...
Subject: RE: Puzzling over stream


On Wed, 7 Jun 2000, Mark Knecht wrote:

>    After I got my system up to 6 FPS, I hadn't gone back to look at what
was
> in /var/log/messages. I think it is very interesting. An endless stream of
> messages stating that listening is first enabled and then disabled. And
> interestingly, these messages come at a rate of 6 per second. 

These messages are caused by the application - remember the patch to
ohci1394.c I sent your way? It tells the driver not to print these
messages unless IEEE1394_VERBOSE_DEBUG is enabled.

Looking at Franck's capture, the core difference is that Franck uses a
separate thread that polls for new iso packets in a tight loop, while in
stream, I tell hardware to start/stop iso reception for each frame. That's
where the messages originate from, but it's a symptom rather than the
cause.

Regards,

Daniel.

-- 
	GNU/Linux Audio Mechanics - http://www.glame.de
	      GPG Key ID 89BF7E2B - http://www.keyserver.net

sony vaio

[Thomas 'D. M. <de...@co...>]

hi list,

i know this is a question, which is probably somewhere in the FAQs, but
i wanted to ask you if someone working on 1394 support for the Sony VAIO
notebooks (FAQs are usually somewhat behind of development)

... also i wanted to ask if someone can recommend a nice (and cheap) PCI
card - especially in austria or germany would be appreciated.

	cheers, and thanks for your help

		++dent
-- 
Thomas Mirlacher	Student of ComputerScience, University of Salzburg
de...@co...	http://www.cosy.sbg.ac.at/~dent

RE: Puzzling over stream

[Daniel K. <dan...@st...>]

On Wed, 7 Jun 2000, Mark Knecht wrote:

>    After I got my system up to 6 FPS, I hadn't gone back to look at what was
> in /var/log/messages. I think it is very interesting. An endless stream of
> messages stating that listening is first enabled and then disabled. And
> interestingly, these messages come at a rate of 6 per second. 

These messages are caused by the application - remember the patch to
ohci1394.c I sent your way? It tells the driver not to print these
messages unless IEEE1394_VERBOSE_DEBUG is enabled.

Looking at Franck's capture, the core difference is that Franck uses a
separate thread that polls for new iso packets in a tight loop, while in
stream, I tell hardware to start/stop iso reception for each frame. That's
where the messages originate from, but it's a symptom rather than the
cause.

Regards,

Daniel.

-- 
	GNU/Linux Audio Mechanics - http://www.glame.de
	      GPG Key ID 89BF7E2B - http://www.keyserver.net

RE: Puzzling over stream

[Mark K. <mk...@co...>]

Daniel & Franck,

   After I got my system up to 6 FPS, I hadn't gone back to look at what was
in /var/log/messages. I think it is very interesting. An endless stream of
messages stating that listening is first enabled and then disabled. And
interestingly, these messages come at a rate of 6 per second. 

   I'm going to be somewhat busy for the next few days and may not be able
to spend a lot of time on this, but I have a strong suspicion that there may
be a beat frequency here where we run out of buffer space somewhere, so the
subsystem disables listening, and then the application gets starved for data
and reenables listening. There could be some substantial delays doing this
which lowers the throughput. I've seen this on two systems....

   Franck - specifically, my systems are NOT at 100% utilization, so we may
not be seeing the same things...

Mark

/var/log/messages while running stream:

Jun  5 16:17:34 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:34 bambi kernel: ohci1394_0: listening enabled on channel 63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening enabled on channel 63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening enabled on channel 63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening enabled on channel 63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening enabled on channel 63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening enabled on channel 63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:35 bambi kernel: ohci1394_0: listening enabled on channel 63
Jun  5 16:17:36 bambi kernel: ohci1394_0: listening disabled on iso channel
63
Jun  5 16:17:36 bambi kernel: ohci1394_0: listening enabled on channel 63

-----Original Message-----
From: Franck Bonin [mailto:fra...@ya...]
Sent: Wednesday, June 07, 2000 4:13 AM
To: Daniel Kobras; Mark Knecht
Cc: lin...@li...
Subject: Re: Puzzling over stream


> >    Then I tried it on the 750 MHz machine and
> found I was still only getting
> > about 6 FPS, really no better than my 400MHz
> machine. My understanding of
> > some e-mails over the weekend was that this was
> limited by doing all of the
> > color space conversions in software, so I of
> course thought that a faster
> > machine would do a faster job. This is not what
> I'm seeing. 
> >  
> >    Using 'top' I find that my 400MHz machine is
> only using 60% of CPU when I
> > am streaming to my screen. There is no disk
> activity, and no other major
> > users of CPU cycles while I'm doing this. So why
> isn't stream using more CPU
> > if there is CPU available???
> 
> This was puzzling me too, so I did a bit of
> profiling. capture_frame() seems to be a major
> bottleneck, i.e. the
> application appears to spend a substantial amount of
> time waiting for new
> iso data to arrive. I'm currently looking into the
> OHCI specific
> mmap() API. Otherwise spawning a separate thread for
> iso reception might
> be a cure.

I have already done this experience, with the capture
program.

In capture, iso reception, video decoding, and sound
decoding are in separate threads. CPU is 100% busy
and I can getting about 4~5 FPS on my PII 300Mhz

I am using libdv too, take a look if you want :

http://www.chez.com/kayle/IEEE_1394/capture_0.1.1.tgz

------
Franck Bonin

___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

OHCI and reply packets

[Olivier D. <dai...@el...>]

Hi,
  I noticed in the OHCI specification (release 1.1, January 6, 2000)
that when writing a packet to the Middle Address Space (region between
physicalUpperBound (usually 48h'0001_0000_0000) and 48'hfffe_ffff_ffff),
packets should be acknowledged immediately with an ack_complete instead
of an ack_pending (making the transaction unified). Problem is: when
sending a packet to 48h'fff8_0000_0000 (should be in the Middle Address
Space), the subsystem still send a response packet. Since I don't have a
bus analyzer, I can't say if the ack packet sent for the first subaction
is ack_complete or ack_pending.

  I guess this should not happen. The Middle Address Space seems to be
reserved for unified transactions, which are really useful. Having this
memory region responding correctly to write transactions would make it
easier to support unified transactions as we would not have to patch
handle_incoming_packet() (like Franck Bonin did for it's ether-over-1394
module) every time we want to use them. I don't know if it's the ohci or
ieee1394 module that is responsible of handling this. Probably both of
them... And also, this would encourage the use of addresses other than
CSR addresses (48'hffff_f000_000 to 48'hffff_ffff_ffff) for
communications, which are said to be reserved by the ISO/IEC 13123:1994
standard.

  Maybe there's something I missed and I'm wrong. In this case, I
apologize for my ignorance.

  Regards,

    Olivier

--
Olivier Daigle
Projet Harfang
=C9cole de Technologie Sup=E9rieure
Universit=E9 du Qu=E9bec
(514) 396-8800 ext.7699

New Ether 1394 version

[<fra...@ya...>]

The ether1394 driver should now support bus reset and
node insertion.
I have tested this with my little network of two PC,
but if someone
could see if it works, even on a larger network, I'd
like to ear
about it.

Ether 1394 driver :
http://www.chez.com/kayle/IEEE_1394/ether_1394_0.1.2.tgz
Or
http://www.chez.com/kayle/ieee_1394.htm

-------
Franck Bonin

___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

Re: Puzzling over stream

[<fra...@ya...>]

> >    Then I tried it on the 750 MHz machine and
> found I was still only getting
> > about 6 FPS, really no better than my 400MHz
> machine. My understanding of
> > some e-mails over the weekend was that this was
> limited by doing all of the
> > color space conversions in software, so I of
> course thought that a faster
> > machine would do a faster job. This is not what
> I'm seeing. 
> >  
> >    Using 'top' I find that my 400MHz machine is
> only using 60% of CPU when I
> > am streaming to my screen. There is no disk
> activity, and no other major
> > users of CPU cycles while I'm doing this. So why
> isn't stream using more CPU
> > if there is CPU available???
> 
> This was puzzling me too, so I did a bit of
> profiling. capture_frame() seems to be a major
> bottleneck, i.e. the
> application appears to spend a substantial amount of
> time waiting for new
> iso data to arrive. I'm currently looking into the
> OHCI specific
> mmap() API. Otherwise spawning a separate thread for
> iso reception might
> be a cure.

I have already done this experience, with the capture
program.

In capture, iso reception, video decoding, and sound
decoding are in separate threads. CPU is 100% busy
and I can getting about 4~5 FPS on my PII 300Mhz

I am using libdv too, take a look if you want :

http://www.chez.com/kayle/IEEE_1394/capture_0.1.1.tgz

------
Franck Bonin

___________________________________________________________
Do You Yahoo!?
Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr

Re: Puzzling over stream

[Daniel K. <dan...@st...>]

On Tue, 6 Jun 2000, Mark Knecht wrote:

>    Then I tried it on the 750 MHz machine and found I was still only getting
> about 6 FPS, really no better than my 400MHz machine. My understanding of
> some e-mails over the weekend was that this was limited by doing all of the
> color space conversions in software, so I of course thought that a faster
> machine would do a faster job. This is not what I'm seeing. 
>  
>    Using 'top' I find that my 400MHz machine is only using 60% of CPU when I
> am streaming to my screen. There is no disk activity, and no other major
> users of CPU cycles while I'm doing this. So why isn't stream using more CPU
> if there is CPU available???

This was puzzling me too, so I did a bit of
profiling. capture_frame() seems to be a major bottleneck, i.e. the
application appears to spend a substantial amount of time waiting for new
iso data to arrive. I'm currently looking into the OHCI specific
mmap() API. Otherwise spawning a separate thread for iso reception might
be a cure.

Regards,

Daniel.

-- 
	GNU/Linux Audio Mechanics - http://www.glame.de
	      GPG Key ID 89BF7E2B - http://www.keyserver.net

RE: [libdv-dev] RE: Streaming DV

[Bernhard S. <bs...@gm...>]

Hi Mark,

On Mon, 5 Jun 2000, Mark Knecht wrote:

> James,
>    Would it be possible to share more of the technical details of your
> accomplishments? One of my machines has XFree86 4.0 installed with 2D and 3D
> accelerations for a GeForce card. Unfortunately, when I recompiled the
> kernel for 1394 support, the GeForce driver complained about not being
> installed correctly and RPM didn't want to reinstall. I haven't gotten back
> to trying to fix that one yet.
Porhaps you should get the "source" for the drivers from NVidia and recompile
it with the new kernel. This shold compile and install the NVidia modules for
your actual kernel. Porhaps you didn't select "set version information on all
symbols" in the module section of the kernel. AFAIK the NVidia modules are
compiled for 2.2.14 so they should fail without this option on 2.2.15.

For me this is working with a GeForce (or better Quadro) card but unfortunately
the nvidia driver often locks my system comletely. And it isn't very fast in
immediate mode OpenGL (sorry for the off-topic) which will be bad for using
it for video display.

>    Is the code you did something that is specific to the graphics cards you
> are using, or could it be extended in some way to a general PC graphics
> card? (Assuming some baseline capabilities...
My assumption is that James is totally avoiding the YUV->RGB conversion
by displaying only the Y (grey) data. Together with the Voodoo 1 for output
this could give you the 30 fps.

Unfortunately after a (very short I must admit) look into the libdv sources it looks
to me that there isn't a function returning the complete YUV picture and one
for converting YUV->RGB. Instead the conversion is done block by block so
it should be a bit of work to do simple operations on the picture before color
conversion.

Has anyone implemented such a function (returning the complete YUV picture)
for libdv yet? Porhaps I've to look into xdvplay instead of the libdv sources
(playdv) directly. If I only had time for this :-))

>    My experience here says that showing folks 30FPS live video gets them
> excited about putting resources in to some projects
If it's really the color conversion eating over 50% of the time it should be
possible to implement (porhaps a half size) playback in grey with 25/30 fps.

The idea of using Glide (or OpenGL) for this sounds good as normally the
output using normal X functions really is slow.

Bernhard

Puzzling over stream

[Mark K. <mk...@co...>]

Hi,
   I'm puzzling a bit over the results I'm seeing one all of my PCs when
using 'stream'.
 
   I set up stream the other day and was getting about 4-4.5 FPS, while
Daniel reported getting about 6 FPS on a similar system. Later on I
determined that I had enabled 'Excessive Debugging Output' at kernel compile
and was getting a bunch of unnecessary disk activity. I turned this off and
my frame rate went up to 6 FPS. Everything looked good.
 
   Then I tried it on the 750 MHz machine and found I was still only getting
about 6 FPS, really no better than my 400MHz machine. My understanding of
some e-mails over the weekend was that this was limited by doing all of the
color space conversions in software, so I of course thought that a faster
machine would do a faster job. This is not what I'm seeing. 
 
   Using 'top' I find that my 400MHz machine is only using 60% of CPU when I
am streaming to my screen. There is no disk activity, and no other major
users of CPU cycles while I'm doing this. So why isn't stream using more CPU
if there is CPU available???
 
   Running Seti@Home on this machine uses 99% of the machine, so I know it's
possible to get the machine used, but either stream, or something in the
underlying driver/library stack, doesn't seem overly interested in doing
so.......
 
   Seems to me that at least mathematically I could get to 10 FPS by
understanding this issue.
 
Mark
 
 

RE: Code Licensing Statements

[Mark K. <mk...@co...>]

Thanks Andreas!

-----Original Message-----
From: Andreas Bombe [mailto:and...@mu...]
Sent: Tuesday, June 06, 2000 1:08 PM
To: Mark Knecht
Cc: Linux1394 Developer's Reflector (E-mail)
Subject: Re: Code Licensing Statements


On Tue, Jun 06, 2000 at 09:34:33AM -0700, Mark Knecht wrote:
> Hi,
>    Just checking. I apologize if this is covered explicitly somewhere and
I
> have missed it.
>  
>    What is the licensing position of the code for the ieee1394 subsystem? 
>  
>    I found the file COPYING.LIB in the libraw directory identifying GNU
> licensing, but many of the files themselves do not have GNU headers to
link
> them back to this file. 

Will add them.  The definitive situation is:

Kernel code: GPL
Libraw1394: LGPL

The libraw1394 tar contains some GPL code, but that is autoconf stuff
used only for building the library.  The library itself is LGPL
completely.

-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/

Re: Code Licensing Statements

[Andreas B. <and...@mu...>]

On Tue, Jun 06, 2000 at 09:34:33AM -0700, Mark Knecht wrote:
> Hi,
>    Just checking. I apologize if this is covered explicitly somewhere and I
> have missed it.
>  
>    What is the licensing position of the code for the ieee1394 subsystem? 
>  
>    I found the file COPYING.LIB in the libraw directory identifying GNU
> licensing, but many of the files themselves do not have GNU headers to link
> them back to this file. 

Will add them.  The definitive situation is:

Kernel code: GPL
Libraw1394: LGPL

The libraw1394 tar contains some GPL code, but that is autoconf stuff
used only for building the library.  The library itself is LGPL
completely.

-- 
 Andreas E. Bombe <and...@mu...>    DSA key 0x04880A44
http://home.pages.de/~andreas.bombe/    http://linux1394.sourceforge.net/

Code Licensing Statements

[Mark K. <mk...@co...>]

Hi,
   Just checking. I apologize if this is covered explicitly somewhere and I
have missed it.
 
   What is the licensing position of the code for the ieee1394 subsystem? 
 
   I found the file COPYING.LIB in the libraw directory identifying GNU
licensing, but many of the files themselves do not have GNU headers to link
them back to this file. 
 
   Additionally, is it the intention that the GNU license extend to the code
in the drivers directory? Some, but not all, of these files have GNU
headers. Can this be addressed quickly. I would like to assign engineers but
cannot do so until this is addressed explicitly.
 
   Thanks for your attention.
 
With best regards,
Mark Knecht
 
 
 
   

Re: Using 1394 for inter processore communication!!

[Cyril P. <imp@Orbotech.COM>]

Olivier,

You may want to look at P1394.3 aka PPDT,-
Point to Point Data Transfer protocol.

http://www.pwg.org/p1394/index.html

Regards,
    Cyril.
    
    
=>
=>Dheeren,
=>  I've been working for some time on data exchange between two computers
=>using FireWire. Roughly, I used libraw1394 and an FCP-like method to
=>make some tests. But as my work advances, I realize that I should
=>implement a protocol stack on top of ieee1394.o instead of using
=>libraw1394, which passes raw incoming data to my application without
=>doing any buffering or unfragmentation. I'm currently looking for a way
=>to implement a protocol that would look as standard as possible to
=>exchange raw data between two (or more) computers using 1394. If you
=>have any experience/knowledge about such protocol, I would be happy to
=>work on it. Home made protocole may be great for small applications, but
=>they don't last long.
=>
=>  Ideas are welcome.
=>
=>  Regards,
=>
=>    Olivier
=>
=>dh...@na... wrote:
=>
=>> Hi,
=>>
=>> Most of the messages that I have been reading in this news group are
=>> centred around  DV
=>> support. I would like to learn about any experiences centred around
=>> using the 1394 bus for
=>> inter processor communication environment..
=>>
=>> Thanks,
=>>
=>> -Dheeren
=>>
=>> _______________________________________________
=>> mailing list lin...@li...
=>> http://lists.sourceforge.net/mailman/listinfo/linux1394-devel
=>
=>--
=>Olivier Daigle
=>Projet Harfang
=>(514) 396-8800 ext.7699
=>
=>
=>
=>

--
Cyril Plisko         Cyril.Plisko@Orbotech.COM
System & Network     Yavne, Israel
Administrator        Phone +972-8-942-3571
Orbotech Ltd.        FAX   +972-8-943-8769

I prefer PGP encrypted mail.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3ia
Comment: Requires PGP version 2.6 or later.

mQCNAzIy1yUAAAEEALnq3N5meJGlSs0h67IpHFi2eeyZfH+VFq57AFlpLesWk6Gg
Os5nBZ6al2WJ6+8RfsHlSIH2ExnPHeLL+rFR+Bl2Aj/ryw6WrWJvfoMul4xsgNFq
OKJJZEjZsOVpjd995ybT7gfHh1hjNaouPml/7B5D9DWN9Zch0Yk2MZJW5NR1AAUR
tChDeXJpbCBQbGlza28gPEN5cmlsLlBsaXNrb0BPcmJvdGVjaC5DT00+iQCVAwUQ
NPpEMYk2MZJW5NR1AQGgNwP9G3H3RxQ9Krd4i0daXWVbH/Ic2vHiuef4hPZD+1pQ
7hiBO3O7On+V7bxaOWgf5YZ+1rQQZTBPpz5yN+LuivWDLPGid0kpft13Flrwp51n
4DMxtKswm0bsFdPc+9dGM3T7JwW4aKhXVWBC/jn36nBauwmSjTgoxlOW0O5GQ1B7
9uW0KkN5cmlsIFBsaXNrbyA8Q3lyaWwuUGxpc2tvQE9yYm90ZWNoLkNvLklMPokA
lQMFEDIy1yaJNjGSVuTUdQEB7CED/Rxx7SFfWh0GhC/i5g/xhG3YMJWFJfCaERmO
N/kc+Cjm2gseXiA5k5rREzbyLwLQRlSkxFJCp8CFXm5BECA/7Tg5QioyUiNozka2
JmLdw/dHdvOrwiBYcGnr8MO4PqfX81Qq7zPhcJ97M90cE6ymsQExjEgeF4Ixwfha
IGe6zq3BtB9DeXJpbCBQbGlza28gPGltcEBPcmJvdGVjaC5DT00+iQCVAwUQNPpD
9ok2MZJW5NR1AQEb3QP/TwppFdpYEYfI4KRlO7FxXk8xq8ZWlHEsiBACK29cmqnK
2b7RBFEegGSviK1iSD3BgSz/cIhBg2T2CT0kW7VUtu1UeO8rC8Yd+LGIh7uhe4z7
Koo3+vg6r1GBmJzcy1NBW9Xh9EhEO0ZWCuuTJ/djXGvglIIgllY0ipI4YI0jURW0
IUN5cmlsIFBsaXNrbyA8aW1wQE9yYm90ZWNoLkNvLklMPokAlQMFEDI2TpyJNjGS
VuTUdQEBkfED/1E6DkJpu+IfPNBcvdLPwA2BjUEplQ/ybD08q/g/PC4Bwc4G4GtU
4hO/FMPyglURlF03F9TtF7Qgi6hyfOG3NKSN0HzMKltpFPv7GHTyBtycMV3FRF/X
V4NUYAi7jLuVRHKNaazbIvZ5GteZNFU4qtq+7rhqbtNeVdebwHqmHMXc
=aKPI
-----END PGP PUBLIC KEY BLOCK-----

Re:Sony DFW-V(L)500 shutter

[Bart N. <ba...@cs...>]

Yes I have these values:

Shutter [sec]    value
1/100000        2575
1/5000        2574
1/20000        2573
1/10000        2572
1/4000        2570
1/2000        2566
1/1000        2558
1/500        2542
1/250        2511
1/125        2448
1/60        2311
1/50        2259
1/30        2047
1/15        2046
1/8        2044
1/4        2040
1/2        2033
1        2018
2        1988
4        1928
8        1808


Happy hacking..

Bart Nabbe

--
Carnegie Mellon University
The Robotics Institute
Smith Hall 219
5000 Forbes Ave.
Pittsburgh PA 15213-3891

Phone
 Office :       +1 412 268 7075
 Lab    :       +1 412 268 3346
Fax     :       +1 412 268 5571

Re: Using 1394 for inter processore communication!!

[Olivier D. <dai...@el...>]

Dheeren,
  I've been working for some time on data exchange between two computers
using FireWire. Roughly, I used libraw1394 and an FCP-like method to
make some tests. But as my work advances, I realize that I should
implement a protocol stack on top of ieee1394.o instead of using
libraw1394, which passes raw incoming data to my application without
doing any buffering or unfragmentation. I'm currently looking for a way
to implement a protocol that would look as standard as possible to
exchange raw data between two (or more) computers using 1394. If you
have any experience/knowledge about such protocol, I would be happy to
work on it. Home made protocole may be great for small applications, but
they don't last long.

  Ideas are welcome.

  Regards,

    Olivier

dh...@na... wrote:

> Hi,
>
> Most of the messages that I have been reading in this news group are
> centred around  DV
> support. I would like to learn about any experiences centred around
> using the 1394 bus for
> inter processor communication environment..
>
> Thanks,
>
> -Dheeren
>
> _______________________________________________
> mailing list lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

--
Olivier Daigle
Projet Harfang
(514) 396-8800 ext.7699