linux1394-devel

RE: sony vaio

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

On Fri, 9 Jun 2000, Ian Blenke wrote:

> Sebastien Rogeaux <Seb...@sy...> writes:
> > If it can be a consolation to you, the CXD3222 chipset found in the other
> > vaios is OHCI compliant but is also not working with the linux driver :(
> 
> I've managed to get my PCG-C1XS with the CXD3222 chipset "working" 
> with the OHCI driver. The driver probes correctly, and does report
> a functioning controller.

wow - so you just changed the PCI device id's? ... if so i'll have to check
for my chip (because i don't have the vaio with me right now - it was just a
guess) ... and if i've the same chip i'll try it with a friends cam.

	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: sony vaio

[Ian B. <icb...@2c...>]

Sebastien Rogeaux <Seb...@sy...> writes:
> If it can be a consolation to you, the CXD3222 chipset found in the other
> vaios is OHCI compliant but is also not working with the linux driver :(

I've managed to get my PCG-C1XS with the CXD3222 chipset "working" 
with the OHCI driver. The driver probes correctly, and does report
a functioning controller.

Unfortunately, the only firewire device I've managed to get my hands
on so far was a "Western Digital 1394 Hard Drive"... which simply
didn't do much of anything (under Linux or Win98) without the
"Western Digital 1394 CardBus PC Card" (which only works under
Win98). 

- Ian C. Blenke <icb...@2c...> <ia...@bl...>
http://vaio-pcg-c1.sourceforge.net/

Re: raw1394_read() returns always 0

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

On Fri, Jun 09, 2000 at 03:56:40PM +1000, Sebastien Rougeaux wrote:
> 
> I have upgraded to the latest CVS for both linux1394 and libraw1394,
> and now raw1394_read() always has a return value of zero. Here is
> the result of testlibraw with 1 camera on the bus:
> 
> -------
> 
> Andreas, is it caused by your latest 64/32 bit changes ?

Whoops, yes.  I made the error field to small, forgetting that the ack
is shifted 16 bits to the left.

The (kernel-)raw1394.h had to be changed, so both libraw1394 and
kernel have to be updated from CVS.

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

Re: Puzzling over stream

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

On Fri, 9 Jun 2000, Sebastien Rougeaux wrote:

> Did anybody of the guys working on grabbing dv movies tried the dma mmap
> feature I announced a while ago for the ohci driver ? It is not really 
> generic, but really speeds things up for real-time video capture.

Yes, I'm currently doing that. I'll try to put some code online today so
others can have a look at it. I ran into two problems so far: Apparently
DV packets do not use the sync field to indicate a start of frame so I
must be prepared to copy data from the DMA buffers if a frame wraps
instead of processing it directly. The bigger problem is that I receive
more data than I'd expect. (I don't have any DV docs - perhaps someone
could explain to me what's going on here.) For a PAL stream I usually
(non-DMA) receive 300 frames of 496 bytes each. The first quadlet is the
iso header, the last quadlet contains host controller status
information. Neither of them should be present in the DMA buffers as
they are filled with isochHeader turned off. The meaning of quadlets two
and three is unknown to me, possibly more header stuff. This yields a
packet size of 480 bytes and indeed on a PAL stream I see a sync frame
at regular intervals, but not every 300th frame as expected. It occurs
every 316th frame. Trying to decode such a mangled DV stream
unsurprisingly usually results in a nice segfault. Anyone got a clue
what's going on?

Regards,

Daniel.

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

Re: Puzzling over stream

[Sebastien R. <Seb...@sy...>]

>>>>> "Daniel" == Daniel Kobras <dan...@st...> writes:

Daniel> On Wed, 7 Jun 2000, Matt Pujol wrote:
>> 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.

Daniel> Yes. Unfortunately in the current subsystem implementation, this very
Daniel> big buffer isn't circular but will overflow when processing is too
Daniel> slow. So we have to find workarounds in user space. Franck's capture
Daniel> and my latest version of dvstream use separate threads that do nothing
Daniel> but iso reception into a double (capture) or triple (dvstream)
Daniel> buffer. In earlier versions of my streaming utility, I used a hack
Daniel> that issued a start_iso_rcv/stop_iso_rcv cycle when the application
Daniel> requested a new DV frame. And that's what hardware's got to do with
Daniel> it: the start/stop iso rcv calls basically boil down to a single PCI
Daniel> write, so the cost of these operations seemed relatively low to
Daniel> me. I've done some profiling now and unfortunately there's obviously
Daniel> quite some latency involved between enabling iso reception on the card
Daniel> and receiving the first packets. To give some numbers, when I turn of
Daniel> DV decoder and display calls and only receive iso data, with the
Daniel> threading method I easily get 25 frames/s (PAL) at 10% CPU utilization
Daniel> on a Dual-PIII/450. Using the start/stop method, the CPU is even more
Daniel> idle but frame rate drops to ~16 fps.

Daniel> Bottom line: User space solutions work but aren't pretty. Maybe it'd
Daniel> be better to implement the in-core buffer as a circular buffer.

Did anybody of the guys working on grabbing dv movies tried the dma mmap
feature I announced a while ago for the ohci driver ? It is not really 
generic, but really speeds things up for real-time video capture.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: sony vaio

[Sebastien R. <Seb...@sy...>]

>>>>> "Thomas" == Thomas 'Dent' Mirlacher <de...@co...> writes:

Thomas> On Fri, 9 Jun 2000, Brian Murray wrote:
>> On Jun 7, 17:45, Thomas 'Dent' Mirlacher wrote:
>> 
>> > 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)
>> 
>> Which Vaio? There are hundreds of different models...
>> 
>> * some contain a CXD1947Q which is currently unsupported

Thomas> it's a vaio PCG-F305 - with a CXD1947Q :(

If it can be a consolation to you, the CXD3222 chipset found in the other
vaios is OHCI compliant but is also not working with the linux driver :(

However I plan to buy one of those little toy soon, so I might be
able to have a go at it. Does anyone know what chipset is used in the
new vaio PCG-XGxx series ?

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: sony vaio (CXD1947Q)

[<br...@pr...>]

On Jun 9, 13:30, Thomas 'Dent' Mirlacher wrote:
> 
> > Which Vaio? There are hundreds of different models...
> > 
> > * some contain a CXD1947Q which is currently unsupported
> 
> it's a vaio PCG-F305 - with a CXD1947Q :(

Tell me about it..... I have a Vaio PCG-C1X (picturebook) with one
of the little suckers...

I'd like to build support for it, but apparently Sony aren't willing
to provide any information. On the flip side, it's meant to be similar
to the Adaptec (Pele) chip, and this driver might be usable with
some modification.

I don't know if anyone's tried just plugging in the '1947 PCI id's
to the Adaptec driver and seeing if it works (I haven't gotten
around to it yet).

If/when support does happen, it will probably happen here :
   http://vaio-pcg-c1.sourceforge.net/

Cheers,
Brian.


--
--
-----------------------------------
Brian Murray      Proximity Pty Ltd
http://www.proximity.com.au/~brian/
-----------------------------------

Re: Streaming live video.

[<br...@pr...>]

On Jun 9,  9:19, Sebastien Rougeaux wrote:
>
> Brian> It works well with their UST/MSC system, which assigns a 64-bit
> Brian> nanosecond accuracy timestamp (relative to machine reset time) and a
> Brian> 'media count' (i.e. frame count) to each incoming media unit
> Brian> (i.e. frame) around the circular buffer, so you can accurately match up
> Brian> similarly-labelled incoming audio, detect dropped frames, etc. Outgoing
> Brian> data can also be accurately synced to absolute time and/or other media
> Brian> types. In the case of 1394/DV, you would also want to associate DV
> Brian> timecode and 'time of day' timestamps to incoming frames.
> 
> I am not familiar with the DV format, but isn't there already some kind of
> timestamp encoded in the DV frame already ?

I'm not familiar either, but I understand it has an hh:mm:ss:ff timecode
or equivalent, as well as an (optional?) time-of-day timestamp so 
camcorders no longer need to burn it into the video image.

The UST/MSC stuff is especially meaningful when capturing from analog
sources which don't have their own inherent timestamp. The SGI effectively
assigns a timestamp to the video stream as soon as the signal crosses the
RCA jack, so there is an absolute time basis with which to relate
other incoming/outgoing video, audio, midi events, serial port characters,
keypresses etc. (e.g. you can specify that each serial character is to
be transmitted at a specific UST time).

I only bring it up because at some stage Linux may want a systemic view
of media timestamping, and I thought I'd throw it into the melting pot
now ...

Cheers
Brian.

--
--
-----------------------------------
Brian Murray      Proximity Pty Ltd
http://www.proximity.com.au/~brian/
-----------------------------------

Re: sony vaio

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

On Fri, 9 Jun 2000, Brian Murray wrote:

> On Jun 7, 17:45, Thomas 'Dent' Mirlacher wrote:
> 
> > 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)
> 
> Which Vaio? There are hundreds of different models...
> 
> * some contain a CXD1947Q which is currently unsupported

it's a vaio PCG-F305 - with a CXD1947Q :(

	cheers,

		++dent

-- 
Linux is no REVOLUTION - it's EVOLUTION at operating system level ;)

Re: sony vaio

[<br...@pr...>]

On Jun 7, 17:45, Thomas 'Dent' Mirlacher wrote:

> 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)

Which Vaio? There are hundreds of different models...

* some contain a CXD1947Q which is currently unsupported
* some contain a CXD3222 (?) which is OHCI compliant and therefore supported
* others may contain something different again...

Cheers
Brian.


--
--
-----------------------------------
Brian Murray      Proximity Pty Ltd
http://www.proximity.com.au/~brian/
-----------------------------------

Re: Puzzling over stream

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

On Wed, 7 Jun 2000, Matt Pujol wrote:

> 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.

Yes. Unfortunately in the current subsystem implementation, this very big
buffer isn't circular but will overflow when processing is too slow. So we
have to find workarounds in user space. Franck's capture and my latest
version of dvstream use separate threads that do nothing but iso reception
into a double (capture) or triple (dvstream) buffer. In earlier versions
of my streaming utility, I used a hack that issued a
start_iso_rcv/stop_iso_rcv cycle when the application requested a new DV
frame. And that's what hardware's got to do with it: the start/stop iso
rcv calls basically boil down to a single PCI write, so the cost of these
operations seemed relatively low to me. I've done some profiling now and
unfortunately there's obviously quite some latency involved between
enabling iso reception on the card and receiving the first packets. To
give some numbers, when I turn of DV decoder and display calls and only
receive iso data, with the threading method I easily get 25 frames/s
(PAL) at 10% CPU utilization on a Dual-PIII/450. Using the start/stop
method, the CPU is even more idle but frame rate drops to ~16 fps.

Bottom line: User space solutions work but aren't pretty. Maybe it'd be
better to implement the in-core buffer as a circular buffer.

Regards,

Daniel.

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

raw1394_read() returns always 0

[Sebastien R. <Seb...@sy...>]

I have upgraded to the latest CVS for both linux1394 and libraw1394,
and now raw1394_read() always has a return value of zero. Here is
the result of testlibraw with 1 camera on the bus:

-------

successfully got handle
current generation number: 1
1 card(s) found
  nodes on bus:  2, card name: ohci1394
using first card found: 2 nodes on bus, local ID is 1

doing transactions with custom tag handler
trying to send read request to node 0... completed with 0x00000000, value 0x98a862ed
trying to send read request to node 1... completed with 0x00000000, value 0x80c564ed

using standard tag handler and synchronous calls
trying to read from node 0... completed with 0x00000000, value 0x042269ed
trying to read from node 1... completed with 0x00000000, value 0xd7696bed

testing FCP monitoring on local node
got fcp command from node 1 of 8 bytes: 01 23 45 67 89 ab cd ef
got fcp response from node 1 of 8 bytes: 01 23 45 67 89 ab cd ef

polling for leftover messages

-------

Andreas, is it caused by your latest 64/32 bit changes ?

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Understanding the form of IEEE1394 subsystem

[Rodney S. <ro...@bi...>]

Hi Mark,

There was an overview of the subsystem posted to this list late last year:

http://ies.auc.dk/~thing/1394/GNU-linux-ieee1394.html

Regards,

-- Rodney

Re: ohci laptop ?

[Ben C. <bco...@de...>]

On Fri, Jun 09, 2000 at 08:52:24AM +1000, Sebastien Rougeaux wrote:
> >>>>> "Ben" == Ben Collins <bco...@de...> writes:
> 
> 
> Ben> I have the same card from Ratoc and it works[1] with the ohci1394 driver.
> Ben> However, you have to reload the driver whenever you insert the card so it
> Ben> will detect it.
> 
> Ben> [1] Atleast it detected the card and raw1394 testlibraw was able to probe
> Ben> it for testing.
> 
> Have you tried connecting a device to it ? Is the self-id reception OK ?

Sorry, don't have any devices to attache to it yet, but the self-id seemed
to return ok.

Ben

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bco...@de...  --  bco...@op...  --  bco...@li...  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

Re: the isoRX interrupt when stopping a running IR context.

[Sebastien R. <Seb...@sy...>]

>>>>> "ks" == =?ks c 5601-1987?B?w9a/7MGk?= <ks_c_5601-1987> writes:

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

ks> Is that all right?

I have changed the remove_card() function slightly so that dma contexts
are freed AFTER the interrupts are disabled. This should fix your specific pb,
and should fix some crash that were still hapening upon driver removal.
Changes will be in the next CVS version.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Streaming live video.

[Sebastien R. <Seb...@sy...>]

>>>>> "Brian" == Brian Murray <br...@pr...> writes:

Brian> On Jun 3, 0:47, Daniel Kobras wrote:
>>  As stated in my previous message, I can display live video streams
>> on-screen using linux1394 and libdv. I'm not too happy about the
>> implementation though. What's bothering me most is the internal buffering
>> of iso data in the subsystem. I'd like to drop intermittent frames if my
>> processing is too slow.

Brian> It might be useful to look at the model used by the SGI digital media
Brian> libraries for real-time streamed data (this applies to analog video I/O
Brian> e.g. on the O2, not sure what they do in their 1394 library for iso
Brian> transfers).

Brian> They use a circular buffer with a fixed size (i.e. frames) and incoming
Brian> data just keeps being written around the circle. The kernel/library
Brian> gives you an event (select'able via a file descriptor) when each new
Brian> frame arrives, you then use the mmapped frame data as you wish. It's up
Brian> to you to use the data quickly enough to avoid overflow - if it looks
Brian> like you're running behind, you can opt to skip some frames in the
Brian> buffer. I believe you tell the library when you start and finish using
Brian> the data from a frame, which allows the detection of overflows as well
Brian> as preventing an 'in use' frame from being overwritten.

The current ohci dma mmap system is very similar. You have a ring buffer
and frame completion are signaled to user space. However when a frame buffer
is full, is is removed from the ring. It is inserted back in by the user
app when it has finished processing it. The dma prog discard incoming video 
data if the ring buffer is empty. Detecting dropped frame could easily
been done by the user app using time stamping of some sort.

Brian> It works well with their UST/MSC system, which assigns a 64-bit
Brian> nanosecond accuracy timestamp (relative to machine reset time) and a
Brian> 'media count' (i.e. frame count) to each incoming media unit
Brian> (i.e. frame) around the circular buffer, so you can accurately match up
Brian> similarly-labelled incoming audio, detect dropped frames, etc. Outgoing
Brian> data can also be accurately synced to absolute time and/or other media
Brian> types. In the case of 1394/DV, you would also want to associate DV
Brian> timecode and 'time of day' timestamps to incoming frames.

I am not familiar with the DV format, but isn't there already some kind of
timestamp encoded in the DV frame already ?

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: ohci laptop ?

[Sebastien R. <Seb...@sy...>]

>>>>> "Ben" == Ben Collins <bco...@de...> writes:


Ben> I have the same card from Ratoc and it works[1] with the ohci1394 driver.
Ben> However, you have to reload the driver whenever you insert the card so it
Ben> will detect it.

Ben> [1] Atleast it detected the card and raw1394 testlibraw was able to probe
Ben> it for testing.

Have you tried connecting a device to it ? Is the self-id reception OK ?

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: ohci DMA code.

[Sebastien R. <Seb...@sy...>]

>>>>> "Bart" == Bart Nabbe <ba...@cs...> writes:

Bart> For those of you who are using the Ohci DMA code.  Is there a way to
Bart> determine if the frame in the dma buffer is valid? The DMA has a counter
Bart> right, so if we have the number of bytes in one frame before a frame
Bart> start we have a valid frame. I have some chopped frames one in a while,
Bart> say 1/3 of the new frame and 2/3 the last frame that was on that
Bart> position in the dma buffer.

Bart> Are there also ideas about how multiple cameras should be handled is
Bart> they are to be used with different applications?

Bart> Any suggestions how to do any of this in a nice way?

Currently, using /dev/ohci1394 for dma mapping, the frame interrupt
is generated when the video buffer is full, and then the next video
buffer starts filling up when an iso packet with the sync tag set is
received.

So your video frame buffer will always be full, wether or not data 
are lost. The way to see if a frame is good or not would be to check
wether or not you discarded packets while waiting for the sync bit...
I don't know if this is possible. Or maybe using timestamps of some
kind. Or check wether two packets with the sync bits were inserted
in the same frame...

It is not on my priority list for the moment... but patch/suggestions 
are always welcome.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Understanding the form of IEEE1394 subsystem

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

On Thu, Jun 08, 2000 at 10:32:12AM -0700, Mark Knecht wrote:
>    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.

I started some DocBook documentation using the new kernel-doc
mechanism introduced in the recent 2.3 kernels.  There's really not
much to see yet, except for some inline documentation comments in the
code on a few functions.

>    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?)

raw1394 is a high level driver, yes.  csr.c and guid.c are high level
drivers, too.

highlevel.c is the management of high level drivers (registering and
interfacing to the core) and not a high level driver itself and more a
part of the core.

A high level driver is one that uses the core interfaces to initiate
transactions on the bus or handle incoming transactions by other nodes
by registering a part of the address space every node has.  Or both,
of course.  (raw1394.c and guid.c initiate transactions, csr.c handles
incoming transactions).

> 3) In between:
>  
> ieee1394_core.c
> ieee1394_transactions.c
> events.c

events.c does nothing in the current subsystem and will be removed
soon (it's not in the 2.3/2.4 code).

The core implements the basic 1394 protocol: transactions (as in
matching response packets to sent packets or creating reply packets
for incoming requests after consulting highlevel.c (and thus high
level drivers) about their content), bus resets (aborting pending
requests, handling SelfIDs) etc.

It does not send or reply to received packets on its own, all of that
is done by high level drivers only (to be exact, the contents are done
by the high level drivers).  Even though csr.c and guid.c are
technically independent high level drivers, they are linked to the
core (they aren't separately selectable during configuration) since
they aren't features but more or less requirements (especially csr.c,
which implements the standard registers every node has to have).  Do
not get fooled by that fact about their true nature as high level
drivers.

ieee1394_transactions.c is part of the core but contains mostly tool
functions to create packets and fill in headers for packets.

>  
> 4) Ancillary - Used when required, but not on every transaction:
>  
> csr.c
> guid.c

See above.

> hosts.c

This is the management for hardware drivers just as highlevel.c is for
high level drivers.

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

Re: Lucent OHCI controller (2nd try)

[Sebastien R. <Seb...@sy...>]

>>>>> "Jurgen" == Jurgen Kramer <GTM...@in...> writes:

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

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

Sorry for the delay, I was away.

I have added the lucent chip to the list. It will be on the next CVS
version.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: List Activity

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

On Thu, Jun 08, 2000 at 11:35:39AM -0400, Sven Nguyen-Northcott wrote:
> Is this list still active? I haven't received any mailings in over a month.
> Sorry about the spam...

You don't seem to be subscribed at your mail address.  Go to
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel to
subscribe again.

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

Re: Linux 1394 somewhat unfriendly during boot?

[Sebastien R. <Seb...@sy...>]

>>>>> "Manfred" == Manfred Weihs <e95...@st...> writes:

Manfred> I also observed, that when booting my linux PC (and since I compiled
Manfred> 1394 into the kernel, not into modules, the subsystem is loaded
Manfred> during bootup) several bus resets occur. I do not know if this is bad
Manfred> or unfriendly (the design of 1394 allows bus resets anytime, so it
Manfred> should not hurt, if there are several bus resets), but I think one
Manfred> bus reset should be enough.

I have not tested the ohci driver directly linked into the kernel, and so
I would not recommend using this option yet.

Manfred> I more frequently observed problems in the other direction, that
Manfred> activities of other nodes caused my linux to crash. For example we
Manfred> have 1394-evaluation-boards from Vitana in our 1394-network, and if
Manfred> we press the reset-button on this boards, my Linux pc sometimes dies
Manfred> (either completly hangs up, so that I am not even able to ping it, or
Manfred> it starts a reboot, or during reboot [mostly during fscheck since
Manfred> this takes some time] gets a kernel panic). BTW: The Win boxes also
Manfred> die sometimes, but my linux box does so more frequently.  I am sorry,
Manfred> that I was not yet able to find out, what conditions must exactly be
Manfred> fulfilled to cause such a crash, so I cannot always reproduce it
Manfred> (that is the reason why I did not yet post a bug report to the list);
Manfred> but it seems that the instability grows with the number of active
Manfred> nodes in the network.  I am not sure, if this is caused by a problem
Manfred> of the hardware (Unibrain card) or the lowlevel driver (pcilynx) or
Manfred> by the higher subsystem layers.  But I think that it is rather a
Manfred> software than a hardware problem, because I yesterday tried to press
Manfred> the reset-button of that Vitana-board many times during bootup and
Manfred> linux hang up _after_ the 1394-driver was loaded.

Yes, it is very likely to be sofware related. The linux1394 subsystem is
still very much alpha quality, that is why it is tagged as experimental
in the kernel configuration process.

-- 
Sebastien Rougeaux
RSISE, The Australian National University

Re: Understanding the form of IEEE1394 subsystem

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

Matt and Mark,
  raw1394 is just a highlevel interface for accessing the 1394 bus. It
is built on top of the ieee1394 module. Hierarchically, here is how
stuff is stacked up:

                               Libraw1394
                                   |
                               raw1394.o
                                   |
                               iee1394.o
                                   |
                               ohci1394.o
                                   |
                                hardware

Libraw1394 being the only part in the user-space (outside the kernel).

  Olivier

Matt Pujol wrote:

> Hi Mark,
>
> In researching my Developer's Conference presentation, I ran into the
> same issue, de-encrypting the code.  From what I could/can tell, raw.c
> resides in the space between ohci1394.c and applications space.  My
> understand is that it uses libraw to more directly access the
> hardware.
>
> Matt
>
> Mark Knecht wrote:
>
>> 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
>>
>>
>>
>> _______________________________________________
>> 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...
> ***********************/
>
>

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

Re: Understanding the form of IEEE1394 subsystem

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

Mark,
  I think that highlevel.c is part of the "In between" section you mentio=
ned.
Roughly, it's the code linking the "In between" world to the "Highlevel"
world. Some explanations are required:

  When you want to write a highlevel protocol, the first thing you have t=
o do
is to obtain an highlevel handle (struct hpsb_highlevel*). With this hand=
le,
you associate your highlevel operations (struct hpsb_highlevel_ops*) whic=
h
will give you the support for handling many mechanisms: add_host (when a =
new
ieee1394 card is discovered), remove_host (when an existing ieee1394 card=
 is
removed), host_reset (when a given card receives a bus reset signal),
iso_reveice (when a given card receives isochronous data) and fcp_request=

(when a given card receives data in the FCP CSR region). When you request=
 an
highlevel handle, you give hpsb_register_highlevel() a name for your new
highlevel "protocol" and a pointer to your struct hpsb_highlevel_ops, whi=
ch
contains pointers to your handling functions. When an event happen (add_h=
ost,
remove_host...), the subsystem calls function associated with this event =
for
every highlevel handle existing.

  Then, once you obtained your own highlevel handle, you can register add=
ress
space that will make your custom functions being called upon receptions o=
f
requests for a given address. This mechanism is used to handle asynchrono=
us
read/write/lock functions. If, as an example, you want something to happe=
n
when a write request is received at addresses between  0xfff8_0000_0000 a=
nd
0xfff8_0000_1000, you create a struct hpsb_address_ops that contains poin=
ters
to your write handling function. Then, you call hpsb_register_addrspace()=
 with
your highlevel handle, your struct hpsb_address_ops, 0xfff8_0000_0000 and=

0xfff8_0000_1000.

  Once this is done, when write requests are received in the address rang=
e
just specified, the write function contained in your struct hpsb_address_=
ops
is called. You just have to handle the packet the way you want in your cu=
stom
function.

  This is why I think that highlevel.c should be included in the "In betw=
een"
part rather than in the "Highlevel" part.

  Regards,

    Olivier

Mark Knecht wrote:

> Hi,
>    One of my good software guys and I are starting to dig into the driv=
er
> 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 certainl=
y 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 th=
e 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
>
>
>
> _______________________________________________
> mailing list lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

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

Re: Understanding the form of IEEE1394 subsystem

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

Hi Mark,

In researching my Developer's Conference presentation, I ran into the same
issue, de-encrypting the code.  From what I could/can tell, raw.c resides in
the space between ohci1394.c and applications space.  My understand is that it
uses libraw to more directly access the hardware.

Matt

Mark Knecht wrote:

> 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
>
>
>
> _______________________________________________
> 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...
***********************/