Re: ieee1394 in 2.6.20-rc1 (was Re: Linux 2.6.20-rc1)

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Gene Heskett wrote:
> The camera has been turned back off, but yes, it works absolutely normally 
> now.  With no dv1394 in memory!
> 
> Then with the camera on and kino controlling it:
> [root@coyote ~]# lsmod|grep 1394
> raw1394                32264  4
> ohci1394               39088  0
> ieee1394              305624  2 raw1394,ohci1394
> 
> So we still don't appear to have any use of/for ohci1394.  What the heck 
> is it supposed to be doing?

What's missing in our implementation is that the use count of ohci1394
goes up too once a "high-level driver" uses resources of a host driven
by ohci1394.

The FireWire stack has three layers: Low level (ohci1394 and pcilynx;
control the host bus adapter), mid level (the ieee1394 core) and high
level (protocol drivers: dv1394, eth1394, sbp2, video1394; and the
multi-purpose bridge to userspace: raw1394). The mid level is supposed
to isolate high-level drivers from hardware-specific drivers.

However dv1394 and video1394 break this architecture. Parts of them
access ohci1394 directly. And in practice, sbp2 indirectly breaks this
architecture too because it never got decent DMA mapping implemented,
and what it got in this department bitrotted to a degree that it is
currently not really usable with pcilynx. (AFAIK, I don't have a PCILynx
controller.)

BTW, sbp2 had the same problem with missing use count of ohci1394 too
until Linux < 2.6.17. But it's a little bit harder to get right in raw1394.

> Now, do I need dv1394 to do the export if I were to want to re-write the 
> edited video back to the tape in the camera?

I suppose Kino is exporting DV via raw1394 nowadays too. Raw1394
definitely has the means for it.

Anyway, I'm glad it sort of works for you now.
-- 
Stefan Richter
-=====-=-==- ==-- =--=-
http://arcgraph.de/sr/