[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-firewire
Subject: Re: Linux IEEE-1394 Driver: Mailinglist, Some info
From: Matt Pujol <mattp () propwash ! co ! symbios ! com>
Date: 1998-06-29 23:55:30
[Download RAW message or body]
Emanuel,
For quick and easy isochronous/IEC61883 capability, I suggest you order a Philips
AV Link evaluation kit - you can find ordering information at Philips
Semiconductors; IEEE1394 Multimedia Bus
It is an evaluation kit for the Philips Link that does IEC61883. The nice thing
is that it comes with firmware that makes it look like a 1394 compliant node and
has a data generator that creates IEC61883 formatted isochronous packets. I think
it costs $375USD. Very reasonable when you consider a PC7 for $2500USD. The
Philips kit should be all you need to get isochronous services up and running in
your driver.
BTW, you asked me a question a few months ago about Pele, but I lost it....did you
figure out an answer? If not, feel free to ask again.
Regards,
Matt
Emanuel Pirker wrote:
> Hi!
>
> The mailinglist is up again - Doing some upgrade on the server vanished
> the alias... now the mailing list is handled by QMail and ezmlm.
>
> Below you find a forwarded email (me answering some question about testing
> the driver)... maybe it is of interest.
>
> Bye,
>
> Emanuel
>
> -------------------------------------------------------------------
>
> Hello,
>
> well I test the driver and chip by doing asynchronous transactions.
> Included with the driver source there is the small program testfw. It
> does just an ioctl() on the fwha0 device file. The ioctl parameter is
> recognized by the driver as "do a test by doing a read quadlet/block
> transaction". Indeed, I can read out e.g. the Configuration ROM of another
> device.
>
> Once I borrowed a Sony DS-250 conference camera for a short time. I could
> read out the Configuration ROM, and could compare the values with those
> of the 1394 DV spec. This was the first proof that the driver worked.
>
> At university now I have a test lab consisting of 3 PCs connected by 1394.
> Two are running Linux, one Windows 95. When starting one of Adaptec's
> 1394 diagnostic programs on the Windows PC, both Linux PCs are correctly
> identified as 1394 nodes with the vendor id of Adaptec. This is the proof
> that the driver answers read requests correctly.
>
> Of course, just doing transactions between the Linux hosts (e. g. write to
> a specific location and read afterwards) also reveals the correctness of
> the driver.
>
> I am currently stuck in the node registry. As in Adaptec's PAPI, I want to
> have 1394 device drivers operate on handles, not on node_ids. The handles
> should remain unchanged after bus reset. I call this layer "node
> registry/handle management". It is more complicated than it sounds, but I
> have to implement it now because it is vital for the ability to write 1394
> device drivers. After completion of the node registry I have scheduled to
> do the IP-over-1394... mostly because I do not have a device to use
> isochronous streams in a senseful way (borrowing the camera from a company
> 50 km away just for 1 or 2 days isn't funny after a few times). If
> somebody equipped with a camera or VCR does the isochronous streams while
> I am doing IP1394, would be the optimal case.
>
> If isochronous streams are provided by the AIC driver, writing a DV driver
> should be trivial. It should register a device /dev/fwdvX for each
> attached camera/video recorder. Writes to this device should open an
> isochronous data stream and switch the VCR to recording. Writes should be
> ignored by a camera devices. Reads from this device should set the device
> to "playing" and and the data should be delivered. Via ioctl() some
> parameters (hue, brightness, zoom etc.) should be configurable.
>
> Bye,
>
> Emanuel
>
> ---------------------------------------------------------------------------
> Emanuel Pirker
> epirker@edu.uni-klu.ac.at E.Pirker@FH-Kaernten.ac.at
>
> On Mon, 29 Jun 1998, Peters, Christopher N wrote:
>
> > Hello again,
> >
> > Thank you for your quick response to my firsts question. Now, I would
> > like to ask you one more.
> > Eventually we will be using an AHA-8940 to recieve data from a DV
> > camara, but since we have not
> > written the isochronous driver yet, we would still like to experiment
> > with the card. I was wondering
> > how we could test the card using your driver. For example, what
> > experiments did you run to verify that
> > your driver worked? Do we need any peripherals to comunicate with it,
> > or do we use another 1394 card?
> >
> > thanks
> > Chris Peters
> >
> >
> >
--
=====================================================================
Matt Pujol (970) 223-5100 x9816
1394 Systems/Applications matt.pujol@symbios.com
Symbios Semiconductors
Fort Collins, CO
=====================================================================
[Attachment #3 (text/html)]
<HTML>
Emanuel,
<P>For quick and easy isochronous/IEC61883 capability, I suggest you order
a Philips AV Link evaluation kit - you can find ordering information at
<A HREF="http://www-us2.semiconductors.philips.com/1394/support/index.stm#kit">Philips
Semiconductors; IEEE1394 Multimedia Bus</A>
<BR>It is an evaluation kit for the Philips Link that does IEC61883.
The nice thing is that it comes with firmware that makes it look like a
1394 compliant node and has a data generator that creates IEC61883 formatted
isochronous packets. I think it costs $375USD. Very reasonable
when you consider a PC7 for $2500USD. The Philips kit should be all
you need to get isochronous services up and running in your driver.
<P>BTW, you asked me a question a few months ago about Pele, but I lost
it....did you figure out an answer? If not, feel free to ask again.
<P>Regards,
<P>Matt
<P>Emanuel Pirker wrote:
<BLOCKQUOTE TYPE=CITE>Hi!
<P>The mailinglist is up again - Doing some upgrade on the server vanished
<BR>the alias... now the mailing list is handled by QMail and ezmlm.
<P>Below you find a forwarded email (me answering some question about testing
<BR>the driver)... maybe it is of interest.
<P>Bye,
<P>Emanuel
<P>-------------------------------------------------------------------
<P>Hello,
<P>well I test the driver and chip by doing asynchronous transactions.
<BR>Included with the driver source there is the small program testfw.
It
<BR>does just an ioctl() on the fwha0 device file. The ioctl parameter
is
<BR>recognized by the driver as "do a test by doing a read quadlet/block
<BR>transaction". Indeed, I can read out e.g. the Configuration ROM of
another
<BR>device.
<P>Once I borrowed a Sony DS-250 conference camera for a short time. I
could
<BR>read out the Configuration ROM, and could compare the values with those
<BR>of the 1394 DV spec. This was the first proof that the driver worked.
<P>At university now I have a test lab consisting of 3 PCs connected by
1394.
<BR>Two are running Linux, one Windows 95. When starting one of Adaptec's
<BR>1394 diagnostic programs on the Windows PC, both Linux PCs are correctly
<BR>identified as 1394 nodes with the vendor id of Adaptec. This is the
proof
<BR>that the driver answers read requests correctly.
<P>Of course, just doing transactions between the Linux hosts (e. g. write
to
<BR>a specific location and read afterwards) also reveals the correctness
of
<BR>the driver.
<P>I am currently stuck in the node registry. As in Adaptec's PAPI, I want
to
<BR>have 1394 device drivers operate on handles, not on node_ids. The handles
<BR>should remain unchanged after bus reset. I call this layer "node
<BR>registry/handle management". It is more complicated than it sounds,
but I
<BR>have to implement it now because it is vital for the ability to write
1394
<BR>device drivers. After completion of the node registry I have scheduled
to
<BR>do the IP-over-1394... mostly because I do not have a device to use
<BR>isochronous streams in a senseful way (borrowing the camera from a
company
<BR>50 km away just for 1 or 2 days isn't funny after a few times). If
<BR>somebody equipped with a camera or VCR does the isochronous streams
while
<BR>I am doing IP1394, would be the optimal case.
<P>If isochronous streams are provided by the AIC driver, writing a DV
driver
<BR>should be trivial. It should register a device /dev/fwdvX for each
<BR>attached camera/video recorder. Writes to this device should open an
<BR>isochronous data stream and switch the VCR to recording. Writes should
be
<BR>ignored by a camera devices. Reads from this device should set the
device
<BR>to "playing" and and the data should be delivered. Via ioctl() some
<BR>parameters (hue, brightness, zoom etc.) should be configurable.
<P>Bye,
<P>Emanuel
<P>---------------------------------------------------------------------------
<BR> Emanuel Pirker
<BR> epirker@edu.uni-klu.ac.at E.Pirker@FH-Kaernten.ac.at
<P>On Mon, 29 Jun 1998, Peters, Christopher N wrote:
<P>> Hello again,
<BR>>
<BR>> Thank you for your quick response to
my firsts question. Now, I would
<BR>> like to ask you one more.
<BR>> Eventually we will be using an AHA-8940
to recieve data from a DV
<BR>> camara, but since we have not
<BR>> written the isochronous driver yet,
we would still like to experiment
<BR>> with the card. I was wondering
<BR>> how we could test the card using your
driver. For example, what
<BR>> experiments did you run to verify that
<BR>> your driver worked? Do
we need any peripherals to comunicate with it,
<BR>> or do we use another 1394 card?
<BR>>
<BR>> thanks
<BR>> Chris Peters
<BR>>
<BR>>
<BR>></BLOCKQUOTE>
<P>--
<BR>=====================================================================
<BR>Matt Pujol \
(970) 223-5100 x9816
<BR>1394 Systems/Applications
matt.pujol@symbios.com
<BR>Symbios Semiconductors
<BR>Fort Collins, CO
<BR>=====================================================================
<BR> </HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic